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(54) Offline access in a document control system 

(57) Systems and techniques to provide offline ac- 
cess in a document control system. In general, in one 
implementation, the technique includes: receiving a re- 
quest from a client, and pre-authorizing the client, in re- 
sponse to the request, to allow actions by a user as a 
member of a group of users by sending to the client of- 
fline access information including a first key associated 
with the group, the first key being useable at the client 
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to access an electronic document by decrypting a sec- 
ond key in the electronic document. Receiving a request 
can involve receiving a request from the client to take 
an action with respect to a second document. The tech- 
nique can also include verifying the user at the client as 
an authenticated user, and the offline access informa- 
tion can include user-specific keys, group-specific keys, 
a policy, and a document revocation list. 
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Description 

BACKGROUND OF THE INVENTION 

[0001] The present application describes systems 
and techniques relating to document control, for exam- 
ple, offline access control in a document control system. 
[0002] Traditional document control systems have in- 
cluded servers that store and manage encryption keys 
for documents secured by the system, providing persist- 
ent protection for documents by requiring the server to 
be contacted before a secured document can be 
opened. Such systems have also provided offline capa- 
bilities by caching a cryptographic document key on a 
client to allow the client to open a document for a limited 
time when the user is offline, provided the document is 
first opened while online. Such systems have also been 
able to log document access information, including 
caching of log information while offline, for use in audit- 
ing document access. 

[0003] Conventional document management sys- 
tems have included document permissions information 
associated with documents that allow different groups 
of individuals to have different permissions, and conven- 
tional document viewing software applications have al- 
so included software plug-ins designed to translate doc- 
ument permissions information from a document man- 
agement system format to a format used by the software 
application, i.e., a separate software plug-in required for 
each integration with a document management system. 
Moreover, the extensible Rights Markup Language 
(XrML™) is being defined to theoretically allow a docu- 
ment viewing application to understand resources and 
permissions from any system that complies with the 
XrML™ rules. 

[0004] Many different encryption schemes have been 
used to secure documents. These have included sym- 
metric encryption on a per-document basis, requiring in- 
dividuals to remember passwords for individual docu- 
ments, and combined asymmetric-symmetric encryp- 
tion schemes (e.g., Pretty Good Privacy (PGP™) en- 
cryption) that provide the ability to decrypt multiple doc- 
uments based on the user's single password. In the net- 
work multicast/broadcast context, various encryption 
protocols have also been used that cache encryption 
keys on clients. Many software products directly inte- 
grate with existing enterprise authentication systems (e. 
g., Lightweight Directory Access Protocol). Moreover, 
various systems have also provided functionality to al- 
low users to find the most recent version of a distributed 
document, such as the Tumbleweed Messaging Man- 
agement System™, which secures e-mail systems and 
can send a recipient of an email with an attached doc- 
ument an email notification when the original version of 
the attached document is updated, where the email no- 
tification has a URL (Universal Resource Locator) link 
back to the current document. 



SUMMARY OF THE INVENTION 

[0005] In general, in one aspect, the invention fea- 
tures operations including receiving a request from a cli- 

s ent, and pre-authorizing the client, in response to the 
request, to allow actions by a user as a member of a 
group of users by sending to the client offline access 
information including a first key associated with the 
group, the first key being useable at the client to access 

to an electronic document by decrypting a second key in 
the electronic document. Pre-authorizing the client can 
involve comparing a time of last recorded client-syn- 
chronization with a time of last change in user-group in- 
formation for the user. Pre-authorizing the client can in- 

15 volve comparing current user-group information for the 
user with received user-group information for the user 
from the client. 

[0006] The client can allow actions with respect to the 
electronic document based on document-permissions 

20 information residing in the electronic document. The of- 
fline access information can include document-permis- 
sions information associated with multiple documents, 
including the electronic document, and the client can al- 
low actions with respect to the electronic document 

25 based on these document-permissions information. 
[0007] Receiving a request can involve receiving a re- 
quest from the client to take an action with respect to a 
second document. The operations can also include ver- 
ifying the user at the client as an authenticated user, and 

30 the offline access information can include at least one 
user-specific key, at least one group-specific key, includ- 
ing the first key, at least one set of document-permis- 
sions information associated with multiple documents, 
and a document revocation list. The at least one set of 

35 document-permissions information can be one or more 
policies associated with the second document. The of- 
fline access information can include at least one set of 
document-permissions information associated with a 
specific document selected based on synchronization 

40 prioritization information. The operations can also in- 
clude receiving an offline audit log from the client. 
[0008] According to another aspect, the invention fea- 
tures operations including receiving from a document 
control server, when online, offline access information 

■*5 including a first key associated with a group of users of 
the document control server, and allowing access to an 
electronic document, when offline, by performing oper- 
ations including using the first key to decrypt a second 
key in the electronic document and governing actions 

50 with respect to the electronic document based on doc- 
ument-permissions information associated with the 
electronic document. Governing actions with respect to 
the electronic document can involve obtaining the doc- 
ument-permissions information from the electronic doc- 

55 ument. Governing actions with respect to the electronic 
document can involve identifying a document policy ref- 
erence in the electronic document, and obtaining locally 
retained document-permissions information based on 
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the document policy reference. 

[0009] The operations can also include preventing ac- 
cess to the document, when offline, if a difference be- 
tween a current time and a receipt time of the offline ac- 
cess information exceeds a server-synchronization-fre- 
quency parameter. The server-synchronization-fre- 
quency parameter can be specific to the document. The 
operations can also include maintaining an offline audit 
log, and uploading the offline audit log when online. 
[0010] According to another aspect, the invention fea- 
tures operations including encrypting an electronic doc- 
ument, and incorporating into the encrypted electronic 
document an address of a document control server, doc- 
ument-permissions information, and an encryption key 
useable in decrypting the encrypted electronic docu- 
ment, the encryption key being encrypted with a key 
generated by, and associated with a group of users of, 
the document control server. The encryption key can be 
a session key generated by the document control serv- 
er, and encrypting the electronic document can involve 
encrypting the electronic document using a document 
key. 

[0011] Incorporating can involve incorporating into 
the encrypted electronic document a document security 
payload including the document key and the document- 
permissions information, the document security payload 
being encrypted using the session key. The document 
security payload can also include a document identifier 
assigned by the document control server, and incorpo- 
rating can also involve incorporating into the encrypted 
electronic document a copy of the session key encrypt- 
ed using a public key associated with the document con- 
trol server. Moreover, the document-permissions infor- 
mation can specify access permissions at a level of 
granularity smaller than the electronic document itself. 
[0012] According to another aspect, a system in- 
cludes a document control server that synchronizes of- 
fline access information with a client in response to a 
client request, the offline access information including a 
first key associated with a group, the first key being use- 
able at the client to access an electronic document by 
decrypting asecond key in the electronic document. The 
system includes a client that allows access to the elec- 
tronic document, when offline, by a user as a member 
of the group, using the first key to decrypt the second 
key in the electronic document and governing actions 
with respect to the electronic document based on doc- 
ument-permissions information associated with the 
electronic document. The client can include an agent 
that periodically contacts the document control server 
to synchronize the offline access information. 
[0013] The server can include a server core with con- 
figuration and logging components, an internal services 
component that provides functionality across dynami- 
cally loaded methods, and dynamically loaded external 
service providers, including one or more access control 
service providers. The system can also include a busi- 
ness logic tier having a cluster of document control serv- 



ers, including the document control server, an applica- 
tion tier having the client including a viewer client, a se- 
curing client, and an administration client, and a load 
balancer that routes client requests to the document 

s control servers. 

[0014] The client request can be a request from the 
client to take an action with respect to a second docu- 
ment. The document control server can be a permis- 
sions-broker server including a translation component. 

to The second document can be a document secured pre- 
viously by the permissions-broker server, and the trans- 
lation component can be operable to translate first doc- 
ument-permissions information in a first permissions- 
definition format into second document-permissions in- 

15 formation in a second permissions-definition format in 
response to the request being received from the client. 
[001 5] The server can be a permissions-broker server 
operable to identify information associated with the sec- 
ond document in response to the request. The associ- 

20 ated information can be retained at the server and indi- 
cate a third electronic document different from and as- 
sociated with the second document. The server can be 
operable to relate information concerning the third elec- 
tronic document to the client to facilitate the action to be 

25 taken. 

[001 6] The server can be a permissions-broker server 
operable to obtain and send, in response to the request, 
a software program having instructions operable to 
cause one or more data processing apparatus to per- 

30 form operations effecting an authentication procedure. 
The client can use the authentication program to identify 
a current user and control the action with respect to the 
second document based on the current user and docu- 
ment-permissions information associated with the sec- 

35 ond document. 

[0017] The invention can be implemented to realize 
one or more of the following advantages. A document 
control system can be easily and tightly integrated with 
existing enterprise infrastructure, such as document 

40 management systems, storage systems, and authenti- 
cation and access control mechanisms. Users of the 
document control system can be enabled to perform au- 
thorized actions with minimal annoyance. Client instal- 
lations can be minimized, and server-initiated, transpar- 

■*5 ent client customization can be performed, thereby eas- 
ing the process of deploying an enterprise solution. 
Moreover, the document control system can be de- 
ployed on multiple platforms and not be intimately tied 
to a particular platform. 

50 [0018] Functionality of a client can be pushed onto a 
server, enabling simplified management and deploy- 
ment by minimizing the size and complexity of the client 
application. New functionality affecting the client's oper- 
ations can be implemented at the server without requir- 

55 ing complicated client updates. An authentication sys- 
tem can allow authentication processes to be plugged 
into a client as needed. The authentication system can 
be integrated with multiple different authentication 
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mechanisms, including later developed authentication 
mechanisms. The authentication system can support 
transparent authentication, such as by caching a logon 
ticket for a period of time or by re-authenticating the user 
transparently. The authentication system can ease de- 
ployment. A server administrator can configure user au- 
thentication with a newly developed authentication proc- 
ess, and the new authentication process can be auto- 
matically plugged into the client when authentication is 
to occur. The authentication process can be independ- 
ent of document permissions and actions, and thus au- 
thentication can occur in between actions without need- 
ing to take the nature of the distribution of existing doc- 
uments into consideration. 

[001 9] A document control system can use an existing 
client application with its own representation of docu- 
ment-permissions information, which may not be able 
to represent all the document-permissions information 
used for a document to be controlled. Server plug-ins 
can translate between document-permissions informa- 
tion types, allowing additional document protection con- 
cepts, such as may be present in an enterprise system, 
to be used with the existing client application. Dynamic 
translation and specification of document-permissions 
information at a permissions broker server can create a 
highly versatile and readily upgradeable document con- 
trol system, The system can be readily made backwards 
compatible because the system can translate to older 
formats of permissions as well as provide a different 
document altogether if needed. 

[0020] An offline access model can be provided in 
which a user can be offline the first time they access a 
document. The user need not be prevented from ac- 
cessing a document that they have permission to ac- 
cess simply because they are offline, while at the same 
time the user can be prevented from accessing a docu- 
ment offline that they have been denied access to while 
online. A bounded time can be provided between when 
a revocation is issued and when it takes effect on all 
clients in the system. Moreover, a bounded time can be 
provided between when a policy is modified and when 
all clients use the modified policy. 
[0021] A document information delivery technique 
can be provided that automatically sends information 
concerning different versions of a document to be ac- 
cessed. A document can be tethered to a document con- 
trol system as described, and when the document is 
opened, the system can relate information concerning 
a different document that should be accessed instead. 
Various workflows can be defined. Such workflows can 
ensure that users always have the latest version of a 
document or provide customized user-dependent doc- 
ument delivery. Viewing of a different document can be 
suggested to or forced on the user, or both can be pos- 
sible dependent upon the document. 
[0022] The details of one or more embodiments of the 
invention are set forth in the accompanying drawings 
and the description below. Other features and advan- 



tages of the invention will become apparent from the de- 
scription, the drawings, and the claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

5 

[0023] FIG. 1 is a block diagram illustrating an oper- 
ational environment for a document control system. 
[0024] FIG. 2 is a block diagram illustrating an exam- 
ple document control server. 
w [0025] FIG. 3 is a block diagram illustrating workflow 
in an authentication system. 

[0026] FIG. 4 is a flow chart illustrating an authentica- 
tion technique employed by a server. 
[0027] FIG. 5 is a block diagram illustrating workflow 
15 in a document control system. 

[0028] FIG. 6 is a flow chart illustrating a document 
control technique employed by a permissions-broker 
server. 

[0029] FIG. 7 is a block diagram illustrating workflow 
20 in a document control system integrated with a docu- 
ment repository. 

[0030] FIG. 8 is a block diagram illustrating workflow 
in a document control system integrated with an email 
client. 

25 [0031] FIG. 9 is a block diagram illustrating a docu- 
ment control server corresponding to the example of 
FIG. 2. 

[0032] FIG. 10 is a block diagram illustrating example 
details of the server from FIG. 9. 
30 [0033] FIG. 11 is a block diagram illustrating an offline 
document access model as can be used in a document 
control system. 

[0034] FIG. 1 2 is a flow chart illustrating a synchroni- 
zation operation as performed by a server. 
35 [0035] FIG. 1 3 is a flow chart illustrating a synchroni- 
zation operation as performed by a client. 
[0036] FIG. 14 is a block diagram illustrating compo- 
nents of a secured document. 

[0037] FIG. 15 is a flow chart illustrating a document 
40 information delivery technique employed by a server. 
[0038] FIG. 1 6 is a block diagram illustrating workflow 
in a document control system. 

[0039] FIG. 17 is a flow chart illustrating a document 
information receiving technique employed by a client. 
45 [0040] FIG. 18 is a block diagram illustrating docu- 
ment securing workflow in the document control server 
of FIG. 9. 

[0041] FIG. 19 is a block diagram illustrating server- 
side access control list evaluation workflow in the doc- 
50 ument control server of FIG. 9. 

[0042] FIG. 20 is a block diagram illustrating online 
document viewing workflow in the document control 
server of FIG. 9. 

[0043] FIG. 21 is a block diagram illustrating revoca- 
55 tion workflow in the document control server of FIG. 9. 
[0044] FIG. 22 is a block diagram illustrating audit 
events retrieval workflow in the document control server 
of FIG. 9. 
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[0045] FIG. 23 is a block diagram illustrating a docu- 
ment control system with multiple document control 
servers. 

[0046] Like reference symbols in the various drawings 
indicate like elements. 

DETAILED DESCRIPTION 

[0047] The systems and techniques described can be 
used to realize a document control system, such as may 
be used by an enterprise in connection with document 
management. The document control system can oper- 
ate as a stand-alone system or as a component of an- 
other system. The document control system can provide 
persistent document security by controlling who can 
view documents and what can be done with them, re- 
gardless of where the document resides. As used here- 
in, the terms "document" and "electronic document" 
mean a set of electronic data, including both electronic 
data stored in a file and electronic data received over a 
network, which can be represented as a single docu- 
ment icon in a graphical user interface of an operating 
system (OS) or software application. An electronic doc- 
ument does not necessarily correspond to a file. A doc- 
ument may be stored in a portion of a file that holds other 
documents, in asingle file dedicated to the document in 
question, or in a set of coordinated files. Additionally, as 
used herein, the term "periodically" means recurring 
from time to time, and does not require regular intervals. 
[0048] The systems and techniques described can be 
used with many different types of documents, including, 
for example, PORTABLE DOCUMENT FORMAT™ 
(PDF™) documents. PDF™ documents are in a format 
originated by Adobe Systems Incorporated of San Jose, 
California. A PDF™ document is an example of an elec- 
tronic document in a platform-independent document 
format that can define an appearance of the electronic 
document. This document format can be a platform in- 
dependent storage format capable of storing many dif- 
ferent types of data, including graphics, animation and 
sound, and the defined appearance can be defined for 
multiple types of display devices, providing a document 
originator with control over the look and feel of the doc- 
ument regardless of the final destination device. Using 
documents in this type of format with the techniques de- 
scribed can result in additional advantages for the re- 
sulting systems. For example, the document control 
system can have an architecture that is not tied to a par- 
ticular software development platform (e.g., the system 
can be designed to run on both Java and .NET), and 
can use platform-independent documents, such as 
PDF™ documents. Thus, the document control system 
can readily function across several platforms. 
[0049] FIG. 1 is a block diagram illustrating an oper- 
ational environment for a document control system. A 
network 1 00 provides communication links between one 
or more clients 110, one or more servers 120, and one 
or more enterprise systems 130. The network 100 may 



be any communication network linking machines capa- 
ble of communicating using one or more networking pro- 
tocols, including a local area network (LAN), metropoli- 
tan area network (MAN), wide area network (WAN), en- 

5 terprise network, virtual private network (VPN), and/or 
the Internet. A client 110 can be any machine(s) or proc- 
esses) capable of communicating over the network 1 00 
with a server 120, and the server 120 can be any ma- 
chine(s) or process(es) capable of communicating over 

to the network 100 with an enterprise system 130. Moreo- 
ver, the client(s) 1 1 0 can also communicate with the en- 
terprise system(s) 130. 

[0050] The enterprise system(s) 1 30 can be a storage 
system, an authentication system, a communication 

15 system, and/or a document management system. The 
server(s) 120 can be designed to tightly integrate with 
existing enterprise system(s) 130 and leverage existing 
enterprise infrastructure. For example, theserver(s) 1 20 
can provide rich support for user and group information 

20 in enterprises, where such information may come from 
multiple sources, as is common in large companies that 
have been involved in recent mergers. The server(s) 
120 can provide document security while being minimal- 
ly obtrusive, making the system easier to use and thus 

25 easier to deploy effectively. For example, the server(s) 
1 20 can implement a document control system that pro- 
vides a sophisticated offline-access mechanism, as de- 
scribed further below, that allows users to view docu- 
ments while offline, even if they have not previously 

30 viewed the document while online. Thus, the document 
control system can maintain a low-profile during normal 
operation, making the presence of document security 
less visible, and thus more usable. 
[0051] FIG. 2 is a block diagram illustrating an exam- 

35 pie document control server 200. The document control 
server 200 can include a server core 210 with configu- 
ration and logging components 220, 230. The server 
core 210 can provide a remote procedure call (RPC) in- 
terface to the clients that contact the server 200. An in- 

40 ternal services component 240 can provide functionality 
across methods 250. Other components of the server 
200, including the methods 250 and external service 
providers 260, can be dynamically loaded based on in- 
formation provided by the configuration component 220. 

■*5 The methods 250 can specify the functionality that the 
server 200 exports to the clients (e.g., secure a docu- 
ment, execute an audit query, etc). The external service 
providers 260 can specify external facilities that are 
available to the methods 250 (e.g., storing data, authen- 

50 ticating users, etc). 

[0052] The configuration component 220 can define 
an interface to a configuration object, and the logging 
component 230 can define an interface to a logging ob- 
ject used by the server 200 to log a wide variety of in- 

55 formation. The configuration object can be a server con- 
figuration file (e.g., a ".ini" file read by the server 200), 
and the logging object can be a log file (e.g., a text file). 
Alternatively, the configuration object and the logging 
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object can be local or remote objects defined using a 
standardized interface (e.g., the java standards JMX 
(java management extension) and log4j, respectively). 
[0053] The RPC interface provided by the servercore 
210 can be used to present a method interface to the 
clients: a client can RPC each named method and pro- 
vide an appropriate set of arguments. The server 200 
can initialize itself by reading a set of method classes 
that export the server method interface and define the 
methods that the server 200 will make available to cli- 
ents. The internal services 240 can be internal compo- 
nents of the server that are used across all of the meth- 
ods 250. These can be statically defined and/or dynam- 
ically loaded as dependencies of methods. The internal 
services 240 can include cryptography components, 
document securer processes, and an access control 
evaluation and creation infrastructure. 
[0054] The methods that the server 200 exports to cli- 
ents may depend on additional services with implemen- 
tations that are dependent on a backend infrastructure 
of an enterprise system environment. The external serv- 
ice providers 260 can define a set of service provider 
interfaces that specify the connection(s) between the 
methods 250 and their execution environment. Upon in- 
itialization, the server 200 can load and initialize the set 
of service providers that are needed for this environ- 
ment. The external service providers 260 can include 
default implementations and can be added to over time 
with additional implementations, tailored to different 
backend infrastructures, using the included service pro- 
vider interfaces. 

[0055] Example service providers are discussed be- 
low, but additional or alternative service providers are 
also possible. The definitions of the service providers 
are given in terms of interfaces that the service providers 
implement. These interfaces can be defined generically 
so that they can be implemented across a wide variety 
of systems. Thus, information that crosses system 
boundaries can be defined in simple terms to provide 
greater flexibility in implementation on various systems. 
[0056] An authentication service provider can be used 
to authenticate a user. In the context of computer secu- 
rity, authentication is the procedure by which a program- 
mable machine confirms the identity of another ma- 
chine, and/or the other machine's current user, from 
which a communication has been received. There are 
many types of systems in which authentication can be 
used, and there are many types of events that can trig- 
ger an authentication process, depending on the needs 
of a particular implementation. The authentication sys- 
tems and techniques described herein can be used in a 
document control system as described, or in other sys- 
tems. 

[0057] FIG. 3 is a block diagram illustrating workflow 
in an authentication system. A client 310 can be com- 
municatively coupled with a broker server 320 via a net- 
work 300. When the client 31 0 needs to take an action 
that depends on having an authenticated user, the client 



310 can send a request 350 to the broker server 320. 
For example, when the client 31 0 needs to take an ac- 
tion with respect to a document 305, the client 310 can 
send the request 350. The request 350 can indicate to 

s the server 320 that an update concerning the currently 
approved authentication process, for use in connection 
with the action, is expected by the client 310. The re- 
quest 350 can include information indicating the action 
and/or one or more authentication processes already 

to residentin alocation local to the client31 0; and the serv- 
er 320 can determine, based on this received informa- 
tion, whether to respond to the client's request by send- 
ing an authentication process for use by the client 310. 
[0058] Additionally, the request 350 can represent 

15 multiple communications between the client 31 0 and the 
server 320. The client 31 0 can first communicate to the 
server 320 that the action has been requested, and the 
client requests to know whether authentication is to be 
performed, and if so, how authentication is to be per- 

20 formed. The information identifying the server 320 and 
the document 305 can be included in the document it- 
self, and the server 320 can determine whether user au- 
thentication is needed based on the information identi- 
fying the document 305 and the nature of the requested 

25 action. The server 320 can respond as to whether au- 
thentication is needed, and if so, the type of authentica- 
tion to be used, including potentially multiple types of 
acceptable authentication mechanisms, from which the 
client 31 0 can choose which one to use. If the client 31 0 

30 does not already have the specified authentication func- 
tionality, the client 31 0 can then request a corresponding 
authentication update. 

[0059] The server 320 can be a dedicated authenti- 
cation broker server, or the server 320 can provide other 

35 resources as well. For example, the server 320 can be 
a document control server as described herein, and var- 
ious client-initiated operations (e.g., document viewing, 
revoking and securing) can effectively also be server- 
based operations in that completion of these operations 

40 may require contacting the server; such server-based 
operations initiated by a client can also trigger authen- 
tication using a dynamically delivered authentication 
process. 

[0060] The server 320 can respond to the request 350 
■*5 by obtaining an authentication process 315 and sending 
the authentication process 31 5 to the client 31 0. The au- 
thentication process 315 can be stored by the server 
320 or by another server (e.g., a server in an enterprise 
system). Thus, authentication components can reside 
50 at the client 31 0, on the server 320, and optionally on a 
separate authentication server. Authentication can be 
handled via a service provider interface that allows the 
server 320 to be configured to use an existing enterprise 
authentication mechanism (e.g., password-based au- 
55 thentication), or even to implement a custom authenti- 
cation mechanism that may be developed later (e.g. a 
biometric authentication, or a new smart card system). 
The authentication service provider interface can define 
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the methods that the server 320 uses to authenticate a 
user, and authentication service providers can be imple- 
mented for Windows and LDAP (Lightweight Directory 
Access Protocol) authentication, and also for one or 
more document management systems, such as authen- 
tication using the Documentum® Login Manager in the 
Documentum® content management system provided 
by Documentum, Inc. of Pleasanton, California. 
[0061] The authentication process 315 represents a 
software program having instructions operable to cause 
a machine to perform operations effecting an authenti- 
cation procedure. The authentication process 315 can 
become a component of the client 310 upon receipt or 
stand alone and communicate with the client 310. The 
authentication process 315 can be a plug-in to a docu- 
ment viewing application, such as the ADOBE ACRO- 
BAT® software provided by Adobe Systems Incorporat- 
ed of San Jose, California. The authentication process 
can use an existing interface provided by the client 31 0 
to communicate authentication information to the server 
320 (e.g., the document viewing application can include 
a security handler component 317 that communicates 
with the authentication process 315, such as described 
further below). The authentication process 315 can be 
aclient authentication library (e.g., adynamic link library 
(DLL)) or a server service provider. 
[0062] Thus, the client 310 can be transparently up- 
dated with a new authentication process as a result of 
sending the request 350 to the server 320. The specific 
mechanism(s) of authentication is therefore configura- 
ble, and end-to-end delivery of authentication compo- 
nents can be performed without the user being aware 
of the update. If an administrator changes the authenti- 
cation procedure to be used for a document, all clients 
that attempt to perform an action that requires the spec- 
ified authentication with respect to that document can 
be automatically and transparently updated to be able 
to authenticate using the newly specified mechanism. 
An authentication procedure can even be changed be- 
tween sequential actions on a document, and thus a 
new request 350 can result in a new authentication proc- 
ess 315 being delivered for the same action to be per- 
formed on an already delivered document. 
[0063] The authentication process 315 can imple- 
ment an authentication procedure at the location of the 
client31 0, interfacing and controlling any local hardware 
as needed (e.g., a biometric authentication procedure 
using biometric reading device), and the authentication 
process 315 can use an interface provided by the client 
310 to communicate authentication information back to 
the server 320. The authentication process 315 can im- 
plement a wide variety of different authentication proce- 
dures, including multi-level and/or multi-factor authenti- 
cations depending on the action being attempted. Be- 
cause the authentication process 315 can be dynami- 
cally delivered in response to each request, an organi- 
zation can readily change authentication procedures, 
adding new security features to a document control sys- 



tem as needed. 

[0064] The authentication process 315 can query a 
user at the client 310 for input (e.g., text, biometric data, 
etc.), encode the received input, and return the encoded 

s input to an authentication provider on the server 320 (e. 
g., send the encoded input to the security handler 317 
in the client 310, which forwards the information to the 
server 320). The server 320 can then handle authenti- 
cation, either directly on in conjunction with an authen- 

10 tication server 330. In this pass-through authentication 
mechanism, the client 31 0 can provide credentials to the 
server 320, and the server 320 can work with a third par- 
ty authentication system, such as LDAP or RADIUS to 
authenticate the user. If authentication is successful, the 

15 authentication service provider can return an authenti- 
cated username. 

[0065] Additionally, the server 320 need not be able 
to directly interpret client authentication information. In- 
stead of the client 31 0 giving credentials directly to the 

20 server 320, the client 31 0 can first authenticate and then 
provide some resulting information to the server 320 to 
allow the server 320 to re-verify that the client 31 0 pre- 
viously authenticated. For example, the authentication 
process 315 can contact the authentication server 330 

25 to authenticate the user directly, and a receipt of authen- 
tication can be returned to the server 320. The server 
320 can pass the receipt to the authentication server 
330 and verify that there was in fact a successful au- 
thentication. Thus, the client 310 can provide creden- 

30 tials to a separate authentication system directly and 
then provide an authenticated token to the server 320, 
which can be used to verify the user's identity with the 
separate authentication system. 
[0066] The server 320 can use multiple authentication 

35 service providers. The server 320 can dynamically de- 
liver one or more authentication processes 315 to the 
client 31 0, as needed, using the interface described be- 
low. Such authentication process(es) 315 can be deliv- 
ered securely to the client 31 0 and spoofing can be pre- 

40 vented, such as described below in connection with se- 
cure code library loading. The client 31 0 can also have 
one or more default authentication processes already 
available, such as an authentication library that can cap- 
ture username-password text entry. Such default au- 

■*5 thentication process(es) can include support for user in- 
terface (Ul) customization and a standard format for ex- 
tracting this information within authentication service 
providers. Moreover, the client 310 can retain creden- 
tials for a period of time so that a user need not logon 

50 each time they perform an operation. An example of 
such retaining of client credentials to support offline ac- 
cess is described further below in connection with FIGS. 
11-14. 

[0067] Secure code library loading can be implement- 
55 ed to all the server(s) 320 to push one or more authen- 
tication libraries (e.g., DLLs, java bytecode, javascript, 
etc.) to clients to provide updates or customize clients 
without requiring any action (or knowledge) on the part 
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of the user while also preventing these authentication 
libraries from being spoofed on the client (e.g., by aTro- 
jan horse program). A mechanism can be provided to 
verify the authenticity of the authentication libraries 
downloaded from the server 320. When the server 320 
pushes an authentication library to the client, the server 
320 can compute a hash of the library and also send 
this hash to the client 310, and/or the server 320 can 
sign the authentication library before sending it to the 
client. The hash can be retained locally at the client, and 
the client 310 can ensure the authentication library is 
valid by computing a hash of the authentication library 
and verifying it against the retained value at load time. 
Additionally, a selected set of libraries can be signed by 
the provider, or all the libraries can be signed by the pro- 
vider, and the provider's public key can be retained at 
the client 31 0 (e.g., a DLL can be signed by Adobe when 
the client 31 0 is the ADOBE ACROBAT® software with 
the Adobe public key included). 

[0068] FIG. 4 is a flow chart illustrating an authentica- 
tion technique employed by a server. A request to take 
an action with respect to a document is received at 400. 
In response to the request, an authentication process is 
obtained at 410. The authentication process is sent to 
the client, at 420, for use in identifying a current user 
and controlling the action with respect to the electronic 
document based on the current user and document-per- 
missions information associated with the electronic doc- 
ument. Thus, the authentication mechanism can be 
specified on the server and the appropriate code can be 
downloaded to the client dynamically, as needed, in a 
manner that is transparent to the client. 
[0069] An authentication interface can provide either 
a text-based username-password description or a sin- 
gle authentication library. This can be implemented us- 
ing two types of methods for authentication. The first 
method can take an opaque token (e.g., an uninterpret- 
ed byte string) as well as a username, although the im- 
plementation can choose to ignore either. The second 
method can take a username, password and optionally 
a third argument, which can specify the "domain", or a 
"connect string" if desired. The authentication provider 
can implement its own defense against brute force at- 
tacks, and can have the option to deny authentication 
even if the correct credentials are presented. 
[0070] Implementations can also return an authenti- 
cation reply that specifies whether the user successfully 
authenticated (verified). If verified is false, an additional 
error message indicating why it was not verified (e.g., 
no such user) can be returned; this error message need 
not be returned to the client, but can just be logged on 
the server (so as not to provide the client with helpful 
information that could be used to crack the authentica- 
tion system). A token to be used in future authentication 
attempts can also be returned, although the server can 
ignore this. The username should also be returned for 
verified attempts such that the server can understand 
who has authenticated. The access control list (ACL) 



service provider should be able to take this username 
and canonical ize it. The canonical form of the username 
can be consistently used across workflows, and the def- 
inition^) governing canonical form(s) in the system can 

s vary with implementation. 

[0071] Because the client can authenticate via multi- 
ple methods, the server should be able to describe how 
the client should attempt to authenticate by default, or 
if authentication failed what method to attempt next. The 

10 authentication service provider can describe how au- 
thentication should occur - e.g., via a specific code li- 
brary or via a basic text entry dialog being displayed to 
the user. If a code library is to be used, the server can 
communicate metadata about the code library to the cli- 

15 ent (e.g., a DLL's name, size, etc.). If a basic text entry 
dialog is used, the server can specify what the U I should 
look like to the user - e.g., the title should say "Please 
enter your company LDAP password", and that only two 
fields, "username", and "password" are required. 

20 [0072] In addition to the authentication systems and 
techniques described, document control systems and 
techniques can be provided. These can be combined 
with the described authentication or used separately. 
[0073] FIG. 5 is a block diagram illustrating workflow 

25 in a document control system. A client 51 0 can be com- 
municatively coupled with a permissions-broker server 
520 via a network 500. A document source 530 can also 
be communicatively coupled with the permissions-bro- 
ker server 520 via the network 500. The document 

30 source 530 can be a document repository (e.g., a doc- 
ument management system or a file system) and/or a 
document handling system (e.g., an email system). In 
general, the document source 530 can be considered 
one of two types: (1 ) a document source where a doc- 

35 ument 540 should be expected to be retained and ac- 
cessible in the future, and (2) a document source where 
a document 540 should not be expected to be retained 
and accessible in the future (although it may be in prac- 
tice). 

40 [0074] When the document source 530 is of the first 
type, document-permissions information 550 can be re- 
tained at the document source 530 and sent to the per- 
missions-broker server 520 when needed. Thus, the 
document-permissions information 550 need not be re- 

■*5 tained at the permissions-broker server 520 (although 
such information can be retained at the server 520 in a 
permissions-definition format specified for the server 
520). When the document source 530 is of the second 
type, the document-permissions information 550 can be 

50 generated at the document source 530, at the permis- 
sions-broker server 520, or at the client 51 0, when the 
document 540 is secured to create a secured document 
545, and the document-permissions information 550 
can be retained at the permissions-broker server 520. 

55 The document-permissions information 550 can be an 
ACL that defines the types of actions that are authorized 
for the document 540. Moreover, document-permis- 
sions information can specify access permissions at a 
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level of granularity smaller than the document itself (e. 
g., controlling access to specific page(s), paragraph(s) 
and/or word(s) in the document). 
[0075] The secured document 545 can be encrypted 
using an encryption key generated by the permissions- 
broker server 520, and the secured document 545 can 
include information identifying the server 520 and the 
document 545 (e.g., a link to the server 520 and a doc- 
ument identifier that is unique within the context of the 
server 520). The secured document 545 can be deliv- 
ered to the client 51 0 in any manner (e.g., email, down- 
load from a document repository, received on a compact 
disc, etc.), and the secured document 545 can be a copy 
of another secured document (e.g., an attachment to an 
email forwarded from another source). 
[0076] When the client 510 needs to take an action 
with respect to the secured document 545, the client 51 0 
can determine that the document 545 is secured, extract 
the information identifying the server 520 and the doc- 
ument 545, and send a request 515 to the server 520 
corresponding to the action and including the document 
identifying information. In response to this request, the 
permissions-broker server 520 can translate the docu- 
ment-permissions information 550 into second docu- 
ment-permissions information 555. The second docu- 
ment-permissions information 555 can be sent to the cli- 
ent 510 to govern the action with respect to the docu- 
ment 545 at the client 510. The client 51 0 can be a doc- 
ument viewing application, such as the ADOBE ACRO- 
BAT® software provided by Adobe Systems Incorporat- 
ed of San Jose, California, and the document 545 can 
be a PDF™ document. 

[0077] FIG. 6 is a flow chart illustrating a document 
control technique employed by a permissions-broker 
server. A request from a client to take an action with re- 
spect to an electronic document is received at 600. In 
response to the request, first document-permissions in- 
formation associated with the electronic document is 
identified at 610. The first document-permissions infor- 
mation can be in a first permissions-definition format. 
The identified first document-permissions information is 
translated into second document-permissions informa- 
tion in a second permissions-definition format at 620. 
The second document-permissions information is sent 
to the client to govern the action with respect to the elec- 
tronic document at the client at 630. 
[0078] Referring again to FIG. 5, the first document- 
permissions information 550 can be in a first permis- 
sions-definition format that includes at least one type of 
permission information that cannot be fully defined in the 
second permissions-definition format used in the sec- 
ond document-permissions information 555, and trans- 
lating between the two sets of information 550, 555 can 
involve translating based upon additional information 
associated with the request 515. For example, the first 
information 550 can include time-dependent permission 
information that cannot be fully defined in the second 
information 555 because the permissions-definition for- 



mat includes no notion of time. But this time-dependent 
permission information can be defined in the second 
document-permissions information 555 for the limited 
purposes of the current request by taking the time of the 

s request into consideration. If the first document-permis- 
sions information 550, in conjunction with the time of the 
request 515, indicates that the requested action is au- 
thorized, then this can be represented in the second 
document-permissions information 555; and likewise, if 

to the first document-permissions information 550, in con- 
junction with the time of the request 515, indicates that 
the requested action is not authorized, then this can be 
represented in the second document-permissions infor- 
mation 555. When asubsequent action is requested, the 

15 translation can be performed again based on the time 
of the subsequent request. 

[0079] As another example, the first information 550 
can include user-dependent permissions information 
thatcannotbe fully defined in the second document-per- 

20 missions information 555 because the permissions-def- 
inition format includes no notion of users. This user-de- 
pendent permissions information can include both user 
and group-based document control information and can 
be defined in the second document-permissions infor- 

25 mation 555 for the limited purposes of the current re- 
quest by taking into consideration user-identification in- 
formation obtained via the client 51 0. This user-identifi- 
cation information can be obtained using the authenti- 
cation systems and techniques described elsewhere 

30 herein. When a subsequent action is requested, the 
translation can be performed again based on newly ob- 
tained user-identification information. Moreover, the 
multiple requests received by the permissions-broker 
server 520 can cause the server 520 to store information 

35 525 relating to the actions taken at the client 510 with 
respect to the document 545. These actions can be as- 
sociated with the username, and also with a network ad- 
dress (e.g., an Internet Protocol (IP) address) associat- 
ed with the client (both as reported by the client and as 

40 reported by the server). Requested actions can also be 
considered actions taken, and the stored information 
525 can be used by the server 520 to generate an audit 
of stored actions-taken information associated with the 
document 545, as described further below. The stored 

■*5 information 525 can also include actions performed and/ 
or requested at either the server 520 or the document 
source 530 (e.g., actions performed at the file system, 
document management system, etc.), and a generated 
audit can include this information as well. 

50 [0080] FIG. 7 is a block diagram illustrating workflow 
in a document control system integrated with a docu- 
ment repository 700. A permissions-broker server 730 
can be used to secure documents in the repository 700 
in a batch mode (e.g., when the server 730 is first in- 

55 stalled) and/or as a step in a content management sys- 
tem (CMS) workflow. A securing client 720 can retrieve 
a document 710 from the repository 700. A document 
identifier 715 can also be retrieved and passed to the 
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server 730. The document identifier 715 can be used 
internally by the sever 730 to control actions with respect 
to the content. If the repository 700 is a CMS, the doc- 
ument identifier 71 5 can be the document identifier used 
in the CMS 700, and if the repository 700 is a file system, 
the document identifier 715 can be the URL (Universal 
Resource Locator) of the document. 
[0081] The server 730 can communicate with the re- 
pository 700 using the document identifier 71 5 to obtain 
document-permissions information 740 (e.g., an ACL 
from a CMS or file permissions information from a file 
system). The document-permissions information 740 
can be specific to the document 71 0 or can define per- 
missions for multiple documents (e.g., a policy main- 
tained by a document management system, or a set of 
file permissions maintained by a file system). The ob- 
tained document-permissions information 740 can be 
used by the server 730 to generate an initial ACL for the 
document 710. A set of data 750 that can include the 
initial ACL, the document identifier 715, and a key gen- 
erated by the server 730, can be sent back to the secur- 
ing client 720. The client 720 can use the set of data 750 
to create a secured document 760, which is an encrypt- 
ed version of the document 71 0. This secured document 
760 can include the initial ACL, the document identifier 
715, and the key packaged as part of the document 760. 
[0082] When a client attempts an action with respect 
to the secured document 760 (e.g., attempts to open the 
document 760 or any copies of this document), the doc- 
ument identifier 715 can be retrieved from the docu- 
ment, sent to the server 730 and used to obtain the cur- 
rent ACL for the document 760, where the current ACL 
reflects the current state of the document in the reposi- 
tory 700. Thus, actions taken with respect to the secured 
document can be controlled based on document-per- 
missions information defining current permissions for a 
source document in the document repository 700. The 
source document can be the originally secured docu- 
ment 760, or in the case where secured documents are 
not sent back to the repository 700, the source docu- 
ment can be the original document 71 0. The server 730 
need not store document-permissions information, as 
this information can be retrieved from the repository 700 
and translated whenever access to the document 760 
is requested, although the server 730 may store the doc- 
ument-permissions information for other purposes. 
[0083] FIG. 8 is a block diagram illustrating workflow 
in a document control system integrated with an email 
client 800. The email client 800 can be a plug-in to an 
email system and can be used to secure an attachment 
810 to an email. When a user chooses to secure an 
email attachment 810, the email client 800 can prompt 
the user for the rules they wish to apply to the attach- 
ment and/or the rules can be generated automatically 
based on a recipient(s) list for the email. The rules can 
be converted into an ACL 830 at a securing client 820 
and sent to a permissions-broker server 840. The server 
840 can store the ACL and return a set of data 850, such 



as described above. This data 850 can be used to create 
a secure attachment 860 that includes a document iden- 
tifier, which may be generated and stored at the server 
840, an initial ACL and an encryption key. 

s [0084] When a client attempts an action with respect 
to the secured document 860 (e.g., attempts to open the 
document 860 or any copies of this document), the doc- 
ument identifier can be retrieved from the document, 
sent to the server 840 and used to obtain the current 

to ACL for the document 860, where the current ACL re- 
flects the current state of the document ACL stored in 
the server 840. The sender of the email can interact with 
the server 840 to change the current ACL for the docu- 
ment 860, even after the email has been sent. Thus, ac- 

15 tions taken with respect to a secured document can be 
controlled, and nature of the security on the document 
can be modified, even after the secured document has 
been distributed. 

[0085] FIGS. 5-8 illustrate access control infrastruc- 
20 ture as can be implemented in a document control sys- 
tem. In the context of the server described in connection 
with FIG. 2, an access control service provider can be 
implemented, where access control can be defined in 
terms of access control lists (ACLs). ACLs can map per- 
25 missions (e.g., can print, can view, etc.) to principals (e. 
g., users and groups), and visa versa. The access con- 
trol service provider interface can define the methods 
used by the server to map these principals into a canon- 
ical form that can be consistently used across work- 
so flows. Access control service providers can be imple- 
mented for various systems, such as NIS (Network In- 
formation Service), LDAP, and an email system (e.g., 
Majordomo, which is a public software program prima- 
rily running on UNIX machines to handle internet mailing 
35 lists). Moreover, the access control infrastructure can 
support shared ACLs (e.g., one ACL to be shared 
amongst multiple documents; such shared ACLs can be 
referred to as policies). 

[0086] FIG. 9 is a block diagram illustrating a docu- 

40 ment control server 900 corresponding to the example 
of FIG. 2. The server 900 can support a variety of basic 
features, including: (1) Access Control - the ability to 
control who can access a document and what permis- 
sions they have; (2) Revocation - the ability to revoke a 

■*5 document so that it can no longer be viewed; (3) Expi- 
ration and/or validity intervals - the ability to specify time 
before which and after which the document cannot be 
viewed; (4) Document Shredding - the ability to make a 
document unrecoverable with respect to the document 

50 control server upon the document's expiration by de- 
stroying the document decryption key; (5) Auditing - the 
ability to audit actions performed on a document (e.g., 
viewing, attempted viewing, etc); and (6) Offline Access 
- the ability to access a document when offline. In addi- 

55 tion, features can be easily added without changing the 
architectu re. 

[0087] An authentication service provider 91 0 can be 
implemented as described elsewhere herein, and an ac- 
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cess control service provider 930 can effect the access 
control infrastructure described. ACLs can include a set 
of Access Control Entries (ACEs) and a set of proper- 
ties. ACL properties can apply to the ACL as a whole (e. 
g., expiration date). An ACE can map principals to rules s 
and can include a list of principals, a rule, and a validity 
period for the ACE. When an ACL is evaluated, only AC- 
Es that are within their validity period need be consid- 
ered. Validity periods can allow different users and 
groups to be granted permission to view a document at 10 
different times. For example, an ACE can specify that 
"only members of the public relations staff may view a 
document before its release date, after which anyone 
can view the document." 

[0088] Rules can include of a set of properties and 15 
granted and denied permissions. These permissions 
can be specific to a viewing client application (e.g., the 
ADOBE ACROBAT® software) and/or server defined. 
Additionally, permissions, like properties can be exten- 
sible, so new ones can be added without changing the 20 
ACL format. 

[0089] The server 900 can have its own simple mech- 
anism that allows users to specify Access Control Lists 
using a Securing Client interface without the use of any 
external ACL mechanism. Additionally, third party ACL/ 25 
rights specifications can be translated to the internal 
ACL format used by the server 900. The server 900 can 
integrate with other systems' access control facilities (e. 
g., Document Management Systems, Database Sys- 
tems, File Systems, etc), leveraging the functionality in 30 
these systems. 

[0090] The server 900 can support integrating with di- 
verse user and group repositories that may contain in- 
complete information, and the server 900 can be ena- 
bled to efficiently access this information in a canonical 35 
user-centric manner. Facilities for manipulating ACLs on 
both the server 900 and a client 980 can be provided. 
The server 900 can verify ACLs to ensure they are valid 
before a document is secured, either using a server- 
based document securer 960 or a client-based docu- 40 
ment securer 990. ACLs can be extensible and can al- 
low opaque third party permissions. Moreover, securing 
of documents can be done in an online-fashion, con- 
nected to the server 900, because the server can verify 
ACLs. 45 
[0091] The server 900 can associate ACLs with doc- 
uments in order to specify which principals (e.g., users 
and groups) have which permissions for a document. A 
principal can have multiple names; however, a principal 
should also have a distinguished canonical name. One so 
of the tasks of the server 900 can be translating the var- 
ious names of a principal into its canonical name. While 
both permissions and properties can describe author- 
ized operations, permissions can be boolean valued 
and properties can be of a variety of types. Permissions 55 
can be granted if explicitly granted and not explicitly de- 
nied; undeclared permissions can be implicitly denied. 
[0092] Each document can be associated with a sin- 



20 

gle ACL. Typically this relationship can be 1 :1 , but in the 
case of policies this relationship can be N:1 , where mul- 
tiple documents share the same ACL. The electronic 
document file can contain an immutable snapshot of the 
ACL dating to the time of securing. The server 900 can 
also maintain a copy of the latest ACL, which can be 
modified by authorized individuals. The server 900 can 
canonicalize ACLs (e.g., translate all principal names to 
their canonical forms) before they are used. This can be 
done whenever ACLs are created or modified (e.g., at 
the time of securing, or when ACL definitions are 
changed). Once ACLs are in canonical form, it can be 
much simpler to evaluate ACLs on both the clients 980 
and the server 900 since determining membership with- 
in groups as well as determining relevant authorizations 
for specific authenticated users can be done via basic 
string matching. 

[0093] The server-side evaluation of ACLs for a spe- 
cific user at a specific point in time (e.g., for online view- 
ing, revocation, document audit retrieval, etc.) can be 
implemented within the server 900 directly. The server 
900 can examine the ACL, looking for ACEs that are 
currently valid and that also contain either the authenti- 
cated user or a group in which s/he is a member, and 
then extract the permissions and properties. The server 
infrastructure to handle canonical ization within the serv- 
er 900 can have three tiers. A first tier can be an in-mem- 
ory cache in the server 900 that maps non-canonical 
principals into their canonical forms. A secondary per- 
sistent cache can store canonical mappings and user- 
in-group information; this cache can potentially be used 
across multiple servers 900. The third tier can be the 
access control service provider 930. 
[0094] The access control service provider 930 can 
include a set of principal modules that provide the ca- 
nonical form of some set of non-canonical strings. 
These principal modules can also specify whether the 
canonical form corresponds to a canonical group or a 
canonical user. However, the architecture need not as- 
sume that a specific principal module will generally know 
all answers, or be able to give a complete answer about 
a specific non-canonical string. To support multiple do- 
mains of expertise within the context of user and group 
repositories, each principal module can publish the do- 
main^) over which it is the authority. The process of ca- 
nonicalization, which can be implemented within the 
server 900 directly can take a non-canonical form and 
iteratively refine it by querying modules with authority 
until one declares the returned value as canonical. 
[0095] Methods 970 in the server 900 can be authen- 
ticated-user-centric, because a typical scenario in- 
volves the server 900 determining whether a specific us- 
er has permission to perform an operation, taking into 
account what groups s/he might be in. Many third party 
group mechanisms organize group membership acces- 
sible by "who are members of a group?", but not "which 
groups contain a specific user?" Moreover, in many cas- 
es groups may contain non-canonical forms of users. 
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Thus, the output of group repositories may not be direct- 
ly usable by the server 900, and a translation interme- 
diary can be employed. 

[0096] A very low common denominator can be as- 
sumed for group providers. A group provider can be ex- 
pected to be able to provide a list of known canonical 
groups. Thus, valid groups can be those in the union of 
known groups specified by group modules. Group mod- 
ules can also provide membership information organ- 
ized in a group-centric manner, which can be an efficient 
approach given the implementation of many existing re- 
positories. 

[0097] The server 900 can have the capability to batch 
preprocess group information for subsequent use within 
the system. For example, one server in a group of serv- 
ers can run such a batch operation on adaily basis. This 
can be implemented in the server core and can involve 
enumerating all groups, canonicalizing members, ex- 
amining group nesting and computing the transitive clo- 
sure. Most of the transitive closure computation can be 
within a storage provider 920, since it is natural to per- 
form these types of operations using database systems. 
[0098] A principal can be either a user or a group. 
Principals can be represented as strings. Groups can 
contain principals. Principals can have many alias ex- 
pressions that can be evaluated and reduced to a pri- 
mary canonical form. Users and groups can be of mul- 
tiple domains. A convention involving the name@sub. 
domain.com format used in email addresses can be 
adopted, even if the document control system integra- 
tion is not email-based. Moreover, the specification of 
what the canonical form should be can be left undefined 
in the general system, as this specification can be inte- 
gration-dependent. Examples in a particular integration 
context can be as follows: "herbach@company.com" is 
the canonical form for many strings, including 
"jonathan_herbach@corp.company.com" and "jher- 
bach@company.com"; likewise, "atg@company.com" 
is the canonical form for "atg@sea.company.com". 
[0099] An access control service provider interface 
can include principal providers, which can be divided in- 
to two subtypes: user modules and group modules. The 
goal of these modules can be to provide canonical in- 
formation and group membership information. A princi- 
pal provider can translate a principal, to the best of its 
ability, into canonical form. The principal provider can 
indicate whether the returned value is in canonical form, 
whether it is known to be a group or a user, and how 
long the returned result can be considered valid in a 
cache. A principal provider can have a domain of au- 
thority, specified as a set of regular expression defini- 
tions, and a group provider can enumerate all the groups 
it knows about in its domain of authority. 
[01 00] To support the various server methods 970, us- 
er and group information can be provided logically, as 
there might be multiple sources of such information. 
Thus, there can be several User Modules and several 
Group Modules. From a high level, each one can be con- 



figured differently, can interface with different backend 
systems, and can be an authority over possibly multiple 
domains. Moreover, defining different modules as do- 
main authorities can assist in providing extranet sup- 
s port. 

[0101] Configuration of the principal modules can de- 
scribe the appropriate class file. Each module can also 
have some module-dependent configuration informa- 
tion, such as connect strings and preferences, as well 
10 as infrastructure to configure what the authorities are. 
Different implementations can also have a rule govern- 
ing pre-processing and post-processing to facilitate in- 
tegration with the rest of the system. 
[0102] An ACL manager 940 can contain code rele- 
ts vant to loading an arbitrary number of principal provid- 
ers. FIG. 10 is a block diagram illustrating example de- 
tails of the server from FIG. 9. The server can have a 
primary in-memory cache, handled by an ACL manager 
1010, for group membership or canonical mappings. 
20 The user can store within memory the recent canonical 
mappings such that the service providers need not be 
called for common requests. 

[0103] The ACL manager 1010 can also include 
cross-method code, and an ACL Service Provider Man- 

25 ager 1 020 can be a transparent interface to storage-lev- 
el (e.g., cross-server) caching. Queries to the ACL Serv- 
ice Provider Manager 1020 can first result in checking 
whether a storage provider 1 030 has the necessary in- 
formation, and return that. If not, the ACL Service Pro- 

30 vider Manager 1 020 can issue queries to user and group 
modules 1040 and attempt to persist as much informa- 
tion to the storage layer as possible. Cache entries can 
be cleaned as per an expiration associated with the ca- 
nonical result returned (e.g., as specified by either the 

35 storage provider or the principal modules). 

[0104] Referring again to FIG. 9, a storage service 
provider 920 can provide an interface that describes a 
collection of methods that the server 900 uses to create 
and retrieve data in persistent storage. This interface 

40 can be the largest service provider interface in the sys- 
tem and can grow further as new integrations and fea- 
tures are implemented in a document control system. 
The storage service provider 920 can provide methods 
in the following areas: (1 ) Allocation of document tickets 

■*5 - each document that is secured on the server can be 
given a ticket with a GUID (global unique identifier); (2) 
Recording document revocation; (3) Saving encryption 
keys for users, groups, documents, and the root server 
keys; (4) Caching user alias and group membership da- 

50 ta; (5) Auditing user access and securing; (6) Manage- 
ment and storage of named ACLs or policies; (7) Stor- 
age and retrieval of the current ACLs for documents; (8) 
Creation of initial ACLs for documents. 
[0105] The storage provider interface can be de- 

55 signed to allow multiple implementations across a wide 
variety of backend systems. This can be done using a 
generic relational database implementation, which can 
workwith both ODBC and JDBC. In addition, the storage 
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provider interface can be designed to support an imple- 
mentation for a content management system, such as 
the Documentum® system. Ticket generation can be 
straightforward. For example, this can be implemented 
by having an integer in the database that is incremented 
on each reservation. Document revocation can be de- 
fined as the ability to revoke a document based upon its 
ticket and to separately query whether the document as- 
sociated with a given ticket has been revoked. The stor- 
age provider can also store and retrieve keys, which can 
be arbitrary byte arrays, by name. 
[0106] The storage provider can also provide storage 
for user alias and group membership data. Alias and 
membership information can be used to evaluate ac- 
cess control lists; the storage provider 920 can be used 
as a cache to help ensure reasonable performance even 
if the access control service provider 930 is not capable 
of providing efficient access to this information. For ex- 
ample, in the limiting case, the access control informa- 
tion might come from flat files that provide the required 
data. When caching user and group alias information, 
the storage provider can perform retrieval queries based 
upon a principal, much like user and group providers. 
The data returned should be of the same format, also 
providing an indication of the validity. The goal can be 
such that when the server uses user alias or group mem- 
bership data, the server should not distinguish whether 
the data provided is real-time or a cached version. 
[0107] For a given user or group, the canonical name 
of the user or group can be obtained. For a user, all of 
the groups to which this user belongs can be obtained. 
Changes to alias data can be immediately visible. 
Changes to the group membership cache may be more 
complicated, because of transitive closures computa- 
tion (group memberships of groups that contain groups). 
Because of this, group content changes may not be im- 
mediately visible if the server is currently computing the 
transitive closure of groups. 

[0108] Document securing operations and document 
access attempts (whether successful or not) can be au- 
dited through auditing methods of the storage provider 
920. In addition to defining the methods to record secur- 
ing and access events, the interface can also define a 
couple of query methods on the audit history - querying 
by document ticket and by user. The storage provider 
can also implement methods that allow ACL creation 
and modification. These methods can be used to keep 
auditing history information. Multiple implementations of 
the storage service provider 920 can be implemented 
as needed, including using a relational database and/or 
using existing document management system notions 
of audit logs (e.g., Documentum® audit trail objects). 
[0109] The storage provider 920 can store and re- 
trieve ACLs by name. An ACL can be a private ACL (e. 
g., for a particular user) or a public ACL. Public ACLs 
represent policies that are intended to be shared across 
multiple documents secured by various users. The 
stored representation of an ACL can be a matter of con- 



cern only to the storage provider, as the provider imple- 
mentation can be designed to simply take ACLs as ar- 
guments and return ACLs as results; the ACLs can be 
described in terms of an AccessControlList interface. 

s [0110] The storage provider can have a set of meth- 
ods to create, update, delete, and retrieve ACLs. The 
methods can take arguments describing either a named 
ACL or a policy (e.g., a public ACL). There can also be 
methods to associate a stored ACL with a given docu- 

10 ment (via the ticket GUID). When associating a given 
document with an ACL, ticket data can also be stored. 
This ticket data can be specific to a particular document 
and can be used to store document-specific information 
like the date when the document was secured as well 

15 as which principal secured the document. An ACL 
shared amongst documents can also specify controls 
relative to the time of securing or to the person who se- 
cured the document. The ticket data can also be used 
by the securing client to provide information correspond- 

20 ing to the service provider. For example, in a Documen- 
tum® system integration the ticket data can provide the 
Documentum® GUID for the source document. The 
service provider information can also be a byte se- 
quence received from the service provider including a 

25 set of name/value pairs that capture appropriate infor- 
mational aspects of the document corresponding to the 
service provider. 

[0111] In addition to the ability to retrieve ACLs by 
their name, the server can also retrieve an ACL for a 

30 specific document. When retrieving an ACL for use, the 
server can optionally provide a principal as a parameter. 
This provides a hint, allowing an optimized storage pro- 
vider to return the subset of an ACL that is relevant for 
that particular principal. 

35 [0112] When creating and storing an ACL, there is al- 
so the opportunity to pass through service-provider spe- 
cific data that was presented to the securing client. This 
can provide an end-to-end mechanism to give a hint to 
the service provider on what specific ACL this document 

40 refers to. This is analogous to the capability described 
above in connection with the ticket data, but may be spe- 
cific to an ACL as opposed to a document. 
[0113] The storage providers need not interpret 
ACLs. The storage provider can simply store and re- 

■*5 trieve ACLs without doing any interpretation of them. 
When a document is created it can be given an initial 
ACL, which can be stored in the document and used for 
offline access control if no other ACL for the document 
exists locally atthe client. The storage interface can pro- 

50 vide the methods by which these current and initial ACLs 
are passed back to the securing or viewing components 
of the server. In general, there can be two main cases: 
(1 ) the content being secured does not have any sepa- 
rate identity outside of the document control system (e. 

55 g., the content is an email attachment); (2) the content 
does have an identity outside of the document control 
system (e.g., the content is a PDF™ rendition of a doc- 
ument inside a Documentum® repository). In this latter 
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case, the service provider should be able to dynamically 
control access to the content in terms of the current rules 
the repository applies to the object from which the con- 
tent was derived. Moreover, once an ACL has been 
saved, it can be modified by the owner, or by a system 
administrator in the case of a policy. 
[01 14] Both the initial and the current ACL can be gen- 
erated by the storage service provider, and access con- 
trol for the content can be mediated in terms of the ac- 
cess control on the underlying object. Otherwise, the 
management of the content may be precisely the same, 
in both the online and offline case. In addition, a Boolean 
supportsProvider method can be provided that the client 
can use to see what service(s) are supported by the 
service provider. The client can thus have an expecta- 
tion of which service provider it can use, and can deter- 
mine from the supportsProvider method if this service is 
actually supported by this document control server con- 
figuration (e.g., this determines what set of name/value 
pairs can be legally included in the service provider in- 
formation in the ticket data). If supportsProvider() is true 
for some service, then the remainder of the interface 
should be implemented. Thus, a customer could use the 
same server both to protect content in a document re- 
pository and to protect email attachments. 
[0115] The server 900 can also include a cryptogra- 
phy component 950, which can have duplicate imple- 
mentations that take advantage of various native cryp- 
tography components (e.g., Java Cryptography Exten- 
sion or. Net Crypto components). In general, a docu- 
ment control server uses several cryptographic primi- 
tives. These cryptographic primitives' implementations 
can be placed behind general interfaces, allowing the 
implementations to be changed (e.g., change key sizes, 
etc.) as needed, such as to add security features and/ 
or to address the needs of specific enterprises. Addi- 
tionally, these cryptographic primitives' implementations 
can use standard cryptographic operations as well as 
custom operations. 

[0116] The interface of the cryptography component 
950 can provide support for the following primitives: (1 ) 
symmetric encryption and decryption (e.g., 128-bit AES 
(Advanced Encryption Standard) and/or 128-bit RC4 
(Rivest Cipher 4)); (2) public key encryption and decryp- 
tion plus signing and verification (e.g., 1024-bit RSA); 
(3) message authentication code (MAC) used to provide 
document integrity (e.g., the one-way HMACSHA1 hash 
function with a 128-bit key); (4) a secure hash function 
for which it is computationally infeasible to find two mes- 
sages that hash to the same value (e.g., SHA1 ); and (5) 
random number generation used to create cryptograph- 
ic keys and introduce randomness into messages (e.g., 
the Secure Random number generator provided with 
the .Net framework for a .Net implementation and the 
java.SecureRandom class for generating random num- 
bers in a Java implementation). These cryptography 
primitives can be implemented in Java using the Java 
Cryptography Extension (JCE) mechanism and in one 



of the .NET languages using the .Net Service Provider 
mechanism. This cryptography interface and the cryp- 
tography implementations should also be used on the 
clients, as both the clients and the servers in the docu- 

s ment control system can secure and access documents 
using these cryptography techniques. The cryptography 
interface can also be implemented in C++ for any cryp- 
tographic operations used on clients written in C++. 
[0117] FIG. 11 is a block diagram illustrating an offline 

to document access model as can be used in a document 
control system. A client 1110 can be communicatively 
coupled with a document control server 1 1 20 via a net- 
work 1 1 00. The document control server 1 1 20 can pro- 
vide multiple offline usage models, including a lease 

15 model similar to traditional offline access models, where 
the user must be online the first time a document is ac- 
cessed and can subsequently access the document of- 
fline for a specified period of time, i.e., the lease period. 
In addition, the document control server 1120 can pro- 

20 vide an initial access model, where the user can be of- 
fline when the document is accessed for the first time. 
As used herein, the term "online" means the client 1110 
can communicate with the server 1120; thus, the client 
1 1 1 0 is connected with the network 1 1 00, and the server 

25 1 1 20 is operational, when the client 1110 is online. 
[0118] In general, the client 1110 and the document 
control server 1120 periodically synchronize to update 
any changes to offline access information retained at the 
client 1110, where this offline access information can ef- 

30 fectively pre-authorize the client to allow actions with re- 
spect to secured documents that have yet to be ac- 
cessed while the client 1 1 1 0 is connected to the network 
1100 (e.g., a secured document received via email at 
the client but not yet opened). The client 1110 can send 

35 a request 1 130 to the document control server 1120. The 
request 1130 can be for an update to its offline access 
information. For example, an agent can be provided with 
the client 1110 that periodically connects to the server 
1120 and downloads offline access information; this 

40 synchronization operation can happen silently in the 
background without a user of the client 1110 being 
aware of the updates; the next time the user attempts 
to open a document, the downloaded offline access in- 
formation can be used by the client for future access 

45 while offline. 

[0119] The request 1130 can be any type of request 
sent to the server 1120 periodically, such as a request 
from the client 1110 to take an action with respect to a 
document 1135, which may be located at the client 1110 

50 or elsewhere and may be a secured document or not. 
The server 1 1 20 can verify an authenticated user at the 
client 1 1 1 0 in connection with the request 1 1 30, and this 
verification of an authorized user can cause the syn- 
chronization operation to initiate. For example, the serv- 

55 er 1120 can be a server such as any described above, 
and the synchronization operation can piggyback on 
other operations that use authentication (e.g., when a 
user attempts to access or secure a document while on- 
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line). Alternatively, synchronization can occur without 
prior authentication; the server 1120 can encrypt the of- 
fline access information using the user's public key so 
that only the user can decrypt them; the encrypted of- 
fline access information can be retained by the client 
1110, and when the user next attempts to open a docu- 
ment, the retained information can be decrypted and 
used to update the client's secure local database as de- 
scribed further below. 

[0120] When the client 1110 synchronizes with the 
server 1120, the server 1120 can send offline access 
information 11 40, which includes a key 1 145 associated 
with a group of users to which the current user belongs 
(a picture of a key is used symbolically in the figures to 
represent one or more encryption keys). The key 1145 
can be used to access a secured electronic document 
1150 while offline by decrypting a second key 1155 in 
the electronic document 1 1 50. The electronic document 
1150 can include content encrypted with the key 1155, 
and the electronic document 1150 can include the key 
1155 encrypted with the key 1145. Alternatively, there 
can be one or more levels of indirection in this key en- 
cryption relationship. For example, the key 1145 can be 
used to decrypt the key 1 1 55, which can be used to de- 
crypt another key that is then used to decrypt the content 
of the document 1 1 50. Regardless of the number of lev- 
els of indirection and the number of keys employed, the 
key 1145, which is associated with a group of users, can 
be used to access the secured electronic document 
1150 while offline by decrypting a second key 1155 in 
the electronic document 1150. Additionally, the offline 
access information 1140 can include other group-spe- 
cific keys, one or more user-specific keys, at least one 
set of document-permissions information associated 
with multiple documents (e.g., a policy as described 
above), and a document revocation list. 
[0121] The synchronization operation can also in- 
volve the client 1110 sending back to the server 1 120 an 
offline audit log 11 60 of operations performed by the cli- 
ent while offline. Thus, the client can periodically syn- 
chronize with the server to upload audit log messages 
that have been retained locally and to download the lat- 
est revocation list and any updates to policies. In a sys- 
tem employing ACLs as described above, all new ACLs 
need not be downloaded with each synchronization be- 
cause of the potentially large number of ACLs in the sys- 
tem. The document control system can provide a con- 
strained set of guarantees as to the freshness of data. 
The guarantees used can be as follows: (1) Each doc- 
ument-specific ACL and policy specifies a period of of- 
fline validity (e.g., a number hours or days for which the 
document-specific ACL is valid before another synchro- 
nization with the server is needed, and after which, the 
document may not be viewed offline without synchroni- 
zation). (2) At each synchronization, all revocations and 
policy updates are synchronized with the client. Thus, a 
policy or revocation list can be at most a specified 
number of time units out of date with respect to a par- 



ticular document. Moreover, the synchronization can al- 
so send a current ACL for any document being ac- 
cessed while online. 

[0122] FIG. 12 is a flow chart illustrating a synchroni- 
s zation operation as performed by a server. A request is 
received at 1200. In response to the request, the server 
determines if an update is needed at 1 21 0. For example, 
the server can compare a time of last recorded client- 
synchronization with a time of last change in user-group 
to information for the user, or the server can compare cur- 
rent user-group information for the user with received 
user-group information for the user from the client (e.g., 
the client can identify to the server its currently retained 
user and group keys, and the server can respond based 
15 on whether any changes to the client's retained keys are 
needed). 

[0123] If an update is needed, the server sends offline 
access information at 1220. This can involve the server 
sending the client a list of the keys to remove and the 

20 keys to add locally. If no update is needed, the server 
sends a validation of the current user-group information 
at 1230. This indicates to the client that current offline 
access information is valid, and the client and server are 
synchronized as of the current time. Additionally, when 

25 the server sends the offline access information at 1220 
or revalidates the client's offline access information at 
1 230, the server can also send a server-reference time 
to be recorded at the client and used in determining 
when a client-server synchronization is needed again in 

30 the future. Finally, the server receives an offline audit 
log from the client at 1 240. Thus, the server can gener- 
ate audits, as described above, that include information 
relating to actions taken with documents while offline. 
[0124] FIG. 13 is a flow chart illustrating a synchroni- 

35 zation operation as performed by a client. Offline access 
information, including a first key, is received, and an of- 
fline audit log is uploaded to a server when the client is 
connected to the network at 1 300. The client retains the 
offline access information at 1310. Cryptographic keys 

40 and other sensitive information can be retained locally 
on the user's machine in a secure manner, such that an 
attacker can not gain easy access to such information. 
[0125] Security may be provided by encrypting the 
files with a cryptographic key stored in tamper-resistant 

■*5 hardware, such as asmartcard or an embedded security 
chip, such as those that ship with some laptops provided 
by International Business Machines Corporation of Ar- 
monk, New York. If hardware tamper-resistant storage 
is not available, software obfuscation techniques may 

50 be used to provide some security. The data retained at 
the client can include user and group private keys, a 
document revocation list, updated ACLs for policies, up- 
dated ACLs and security data for documents the client 
has accessed while online, and an offline audit log of 

55 operations performed by the client while offline. 

[0126] A request to access a document is received 
when the client is not connected to the network at 1330. 
A check is made to determine if a recent server synchro- 
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nization has occurred at decision 1340. For example, 
the client can check whether a difference between a cur- 
rent time and a receipt time of the offline access infor- 
mation exceeds a server-synchronization-frequency 
parameter. The server-synchronization-frequency pa- 
rameter can be specific to the docu ment to be accessed. 
Moreover, determining the current time can involve 
comparisons between the last known synchronization 
time and the local system clock. 

[0127] If a synchronization with the server has not oc- 
curred recently enough, the client prevents access to 
the document at 1350. If a synchronization has occurred 
recently enough, the first key is used to decrypt a second 
key in the document at 1360. Actions with respect to the 
electronic document can be governed based on docu- 
ment-permissions information associated with the elec- 
tronic document at 1370. Governing actions with re- 
spect to the electronic document can involve obtaining 
the document-permissions information from the elec- 
tronic document itself. Governing actions with respect 
to the electronic document can involve identifying a doc- 
ument policy reference in the electronic document, and 
obtaining the document-permissions information re- 
tained locally, based on the document policy reference. 
Additionally, an offline audit log, which can record both 
document access and attempted document access, can 
be maintained at 1380. 

[0128] FIG. 14 is a block diagram illustrating compo- 
nents of a secured document 1 400. Included within the 
secured document 1400 can be an encrypt dictionary 
1 405. The encrypt dictionary 1 405 can include encrypt- 
ed keys, which can be used to access the content of the 
document 1400, and an address (e.g., host name, port 
number, and connection protocol) of the server to con- 
tact when online. The encrypt dictionary 1405 can be 
embedded within the encrypted document 1400 in a lo- 
cation that is not encrypted by the document key used 
to encrypt the document (i.e., used to encrypt the doc- 
ument content). 

[0129] An example encrypt dictionary 1410 includes 
document permissions information 1420 (e.g., the initial 
ACL described above) and one or more encrypted doc- 
ument keys 1430. The document key used to encrypt 
the content of the document 1400 can be encrypted mul- 
tiple times using group keys and user keys, and these 
encrypted document keys 1430 can be included in the 
encrypt dictionary 1 405 in the secured document 1 400. 
A document control server can dynamically generate 
and maintain user and group keys for the user and 
groups in a document control system. By including the 
encrypted document keys 1430 and the document-per- 
missions information 1 420 in the document 1 400, offline 
access can be supported by providing the appropriate 
user and group keys to the client using the synchroni- 
zation operation described above. 
[0130] Another example encrypt dictionary 1440 in- 
cludes a document key 1450, an ACL 1460, a document 
ticket 1470, version information 1480 (e.g., a format ver- 



sion string), and encrypted session keys 1 490. The doc- 
ument key 1 450 can be a random 1 28-bit key generated 
by the document control server and used to encrypt the 
document content (e.g., using RC4 or AES encryption). 

s A portion of the encrypt dictionary 1 440 can be encrypt- 
ed using a generated session key, and a MAC can be 
used to detect any modification of the encrypt dictionary. 
The encrypted session keys 1490 can be the session 
key encrypted multiple times using the group keys and 

to the user keys. Additionally, the session key can be en- 
crypted with the server's public key. 
[0131] When a user attempts to open a document of- 
fline, the client can check to see if the session key for 
the document has been encrypted with the user's key 

15 or the group key of any group of which the user is a mem- 
ber. The client can obtain the user's key and keys for all 
groups of which the user is a member during synchro- 
nization with the server. The appropriate key is then 
used to decrypt the information in the document's en- 

20 crypt dictionary. The client can then evaluate the ACL in 
the same way ACLs are evaluated on the server to de- 
termine what permissions the user has. The client's rev- 
ocation list can be checked, and if the document has not 
been revoked and has not expired, the document can 

25 be opened and the user's access to the document can 
be audited locally. 

[0132] This initial access model allows a user to be 
offline the first time they access a document. When the 
document 1 400 is secured, the initial ACL for the docu- 

30 ment can be embedded, immutable, in the document. 
When a user attempts to open the document, the em- 
bedded ACL can be used to determine whether they 
have access. The document 1400 can still be revoked 
or expire even though an initial ACL is kept within the 

35 document. Moreover, the current ACL for the document 
1400 maintained elsewhere can be updated, and this 
ACL can be used when the client is online, as described 
above. 

[0133] When a user accesses adocument online, the 
40 current ACL, which can be stored on the server, can be 
retained on the client and used for that access. The re- 
tained ACL can then be used for future offline access to 
the document. When the client obtains the updated ACL 
from the server, the client can also obtain the document 
45 session key, separately encrypted with the key of each 
user and group that can access the document. Both the 
ACL and the encrypted keys can be secured in a manner 
similar to that initially embedded in the document. 
[0134] Moreover, the document permissions informa- 
50 tion 1420, 1460 in the document can include a policy, i. 
e., a document policy reference or identifier. Thus, the 
client can identify a document policy reference in the 
electronic document while offline, and obtain the docu- 
ment-permissions information of the policy, retained lo- 
ss cally, based on the document policy reference. As the 
document control system can guarantee that all policy 
updates are reflected on the client with each client-serv- 
er synchronization, an administrator can change a pol- 
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icy and know that within a bounded amount of time, the 
change will be reflected on all clients that are still pro- 
viding access to any documents. 
[0135] In addition to the initial offline access model de- 
scribed above, a traditional lease model can also be 
used in the document control system to provide addi- 
tional flexibility. In this model, the first time a user ac- 
cesses a document from a particular machine, they 
must be online. At that time, they receive an offline 
lease, which allows them to view the document for a 
specified period of time offline before the lease must be 
renewed. Such a lease model can be implemented in 
the document control system described by embedding 
an initial ACL allowing access to no principals, and em- 
ploying a validity interval that specifies how long an 
ACL can be retained on the client before a new one 
needs to be fetched from the server. Additionally, the 
document control system can be configurable to enable 
a no-offline-access model in which the user must be on- 
line in order to access a document; in this case, the keys 
needed to open the document need not ever be retained 
on the client. 

[0136] The document control system can provide all 
of the following security guarantees together as well, 
generally subject to the accuracy of client time. (1 ) Pol- 
icy Modification - A policy modification is guaranteed to 
be reflected on each client within the 
offline_validity_interval specified in the policy since all 
policies are synchronized at every synchronization op- 
eration. (2) ACL Modification - A (non-policy) ACL that 
has been modified will be reflected on the client only if 
it is viewed while online. Retained non-policy ACLs are 
guaranteed to be dropped from the client within the 
validity_period if specified in the ACL. (3) Revocation - 
A document that has been revoked is guaranteed to be 
unviewable by all clients in the system within the 
offline_validity_interval, specified in the document's 
ACL since revocation is synchronized with the client at 
every synchronization operation. (4) Expiration - A doc- 
ument that has expired will be unviewable on the expi- 
ration date regardless of whether the user is online or 
offline. (5) Expiration modification - Expiration is speci- 
fied in the ACL, and so expiration modifications are re- 
flected as per-Policy or per-ACL modifications. (6) User 
or Group membership modification - If a user's key is 
revoked (e.g., because they leave the company) or if the 
user is removed from a group, it can be guaranteed that 
the user will not be able to view a document that they 
no longer have access to within the 
offline_validity_interval for the document. 
[0137] FIG. 15 is a flow chart illustrating a document 
information delivery technique employed by a server. A 
request for a client to take an action with respect to a 
first electronic document is received at a server at 1500. 
In response to the request, information associated with 
the first electronic document is identified at 1510. The 
associated information can indicate a second electronic 
document that is different from and associated with the 



first electronic document. This information can associ- 
ate two or more documents and can describe the rela- 
tionship^) between them; this association information 
can be stored at the server, such as in a table or a da- 
s tabase. Information concerning the second electronic 
document is related to the client at 1 520 to facilitate the 
action to be taken. 

[0138] Relating the second document information to 
the client can involve sending the second document in- 
fo formation to the client to allow selection of one of the 
first and second documents with respect to the action. 
Relating the second document information to the client 
can involve obtaining the second electronic document, 
and sending the second electronic document to the cli- 
15 ent to allow taking of the action with respect to the sec- 
ond electronic document instead of with respect to the 
first electronic document. The second document can al- 
ready exist or may need to be generated in whole or in 
part, which can be indicated by the associated informa- 
20 tion indicating the second document. 

[0139] FIG. 16 is a block diagram illustrating workflow 
in a document control system. A client 1 61 0 can be com- 
municatively coupled with a document control server 
1620 via a network 1600. The client 1610 can send a 
25 request 1630 to the document control server 1620, 
where the request 1 630 relates to an action to be taken 
with respect to a document 1 640. The server 1 620 can 
check information 1645, which can be stored locally or 
elsewhere, that is associated with the document 1640 
30 and indicates a second document 1650. The server 
1 620 can then send information 1 655, which can be in- 
formation about the second document 1650 and/or the 
document 1650 itself. 

[0140] The client 1610 can force a user to view the 
35 second document 1 650 based on the information 1 655. 
For example, the second document 1 650 can be a later 
version of the first document 1640, and the information 
1655 can include document-permissions information 
specifying that the action is not permitted with respect 
40 to the first document 1 640. The first document 1 640 can 
be replaced with the second document 1650 (e.g., 
opened in place of the first document and/or written to 
storage over the first document) by the client 1610, in- 
cluding potentially without the knowledge of the user. 
■*5 The second document 1 650 can also be a different lan- 
guage version (e.g., a French version of an English orig- 
inal) or a different format version (e.g., a different file 
compression and/or encryption scheme) of the first doc- 
ument 1640. 

50 [0141] Obtaining the second electronic document 
1 650 at the server 1 620 can involve generating at least 
a portion of the second electronic document 1650 (in- 
cluding potentially generating the entire document 
1 650), or the document 1 650 can be a pre-existing doc- 

55 ument. The associated information 1 645 can include us- 
er-based association information, and obtaining the 
document 1650 can involve obtaining the document 
1650 based on the user-based association information 
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and an identified user at the client 1610. The document 
1 650 can be customized for a particular user, the user's 
location and/or the user's time of access (e.g., the doc- 
ument 1 640 can be astub documentthat is already iden- 
tified as outdated when sent, and when this stub docu- 
ment is opened, each user can automatically receive a 
new document generated specifically for that user at the 
time of the access attempt, i.e., the stub document looks 
like and can be manipulated as a regular document in 
an operating system, but is always current when opened 
while online). Customization of the document 1 650 can 
be done at the server 1 620 or elsewhere. The user can 
be identified as described above, and the document 
control system can also employ the systems and tech- 
niques described throughout this patent application; the 
documents 1640, 1650 can be secured documents as 
described above. 

[0142] FIG. 1 7 is a flow chart illustrating a document 
information receiving technique employed by a client. A 
locally retained distributed document is opened at 1 700. 
The distributed document can be a secured document, 
as described above, that identifies a document control 
server to contact. A document control server identified 
from the distributed document is contacted at 1 71 0. The 
server can determine whether the distributed document 
is the appropriate document, or if a different related doc- 
ument should be used instead. Use of a second docu- 
ment in place of the distributed document is forced at 
1720, with respect to a document action, based on in- 
formation received from the document control server. 
[0143] A document control system can thus address 
both issues of document security and version manage- 
ment in one system. If a different version of a distributed 
document should be viewed in place of the distributed 
version, this can be defined and controlled in a docu- 
ment control server that also handles document security 
for distributed documents. An author of a document can 
specify that a distributed version of a document is out- 
dated, and a newer version should be viewed instead. 
Moreover, an author can easily control multiple versions 
of a document and user-based definitions of who should 
view which version. 

[0144] An author or administrator can designate 
which documents are appropriate versions for which re- 
cipients, including the possibility that two users receive 
entirely different documents with different content and 
which are different document versions in the sense that 
they both relate to an originally distributed document. 
Version relationships among documents can be speci- 
fied using the document identifiers generated for docu- 
ment security purposes. The version relationships can 
be defined using a directed graph in which each node 
is a version, and the directed edges indicate which ver- 
sions take precedence. Each edge can also indicate to 
which users it applies. A graphical user interface for dis- 
playing diagrams can be used to define the version re- 
lationships, such as by drag and drop operations to 
specify which versions become outdated in favor of oth- 



er versions. 

[0145] In the context of different sequential versions 
of a document, where each document can be revised 
and the system can ensure that each user only views 

s the latest version of a document, the notion of revocation 
in the document control system can be extended to in- 
clude whether a document has been replaced with an- 
other. Thus, upon opening a document, in addition to 
checking whether users have access to perform tradi- 

10 tional actions on the document (e.g., print, etc.), a de- 
termination can be made as to whether the user should 
have access to a specific version of the document. The 
server 1620 can store information about where docu- 
ments can be found, including potentially providing an 

15 additional repository service where documents that are 
being persistently versioned can be stored. 
[0146] In the case where each user can view a differ- 
ent version, a similar approach can be used, with the 
addition of the ability to specify intersecting user/groups 

20 (e.g., "instead of version zero, all employees should see 
version A; all managers should see version B; and an 
executive should see version C", where additional ver- 
sion relationship information specifies thatthe executive 
can open the subordinate versions A and B in addition 

25 to version C). Rules for resolving conflicts can be pro- 
vided. 

[0147] The systems and techniques described herein 
can be combined in a comprehensive document control 
system employing multiple document control servers. 

30 Referring again to FIG. 9, the document control server 
900 can implement the various techniques described, 
in combination. To increase system security, all client- 
server communications can be over Secure Socket Lay- 
er (SSL), which encrypts the communications and pro- 

35 vides server authentication, and/or securing of docu- 
ments can be done using client-side securing. The serv- 
er 900 can be physically secured from an attacker and 
can sit behind at least one firewall. All sensitive state 
information in the server 900 can be encrypted before it 

40 is persisted to stable storage; the encryption key used 
for this can be embedded in the server code, hidden in 
obscure system resources and/or contained within a 
tamper-resistant cryptographic module. Moreover, on 
the client side, a user's logon credentials can be cached 

■*5 to avoid repeated authentications for multiple consecu- 
tive operations that require authentication. Cached cre- 
dentials can be signed by a server private key, dedicated 
to this purpose, and reside on the client; the signed cre- 
dential can include an expiration date to limit its validity 

50 period and can be presented when the client attempts 
to authenticate against the server 900. 
[0148] As mentioned above, documents can be se- 
cured either at the server or at the client. A document 
can be converted from one format to another (e.g., from 

55 Microsoft Word to PDF™) before securing; the docu- 
ment control system can be integrated with a PDF™ cre- 
ation service for this purpose. The securer component 
960, 990 can be a wrapper around a PDF™ library that 
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takes a PDF™ document as input as well as an encryp- 
tion key and a set of name/value pairs that represent 
information to be embedded in the PDF™ document's 
encrypt dictionary. The securer can encrypt the docu- 
ment with the provided encryption key and embed the 
specified information in the document. When the secur- 
ing is performed on the server 900, the securing can be 
done in a separate process - a pool of such processes 
can be kept available so that multiple securing requests 
can be simultaneously satisfied, and the maximum 
number of such processes can be a configuration option 
for the server 900. These securing processes can be 
terminated after some number of successful securing 
operations, which number can also be a configuration 
option, or after any unsuccessful securing operation. 
[0149] FIG. 18 is a block diagram illustrating docu- 
ment securing workflow in the document control server 
of FIG. 9. Securing a document can generally involve 
two high-level operations: preparing system state asso- 
ciated with securing of a document, and embedding rel- 
evant information into the document and encrypting it. 
Preparing state can be ajoint operation between the se- 
curing client, specifying how a document should be se- 
cured, and the server, which can prepare the system for 
the secure document. Embedding information into the 
document and securing can be done either on the server 
(e.g., the unencrypted document is sent up to the server 
at time of securing and then the encrypted form is re- 
turned to the client), or on the client (e.g., the client has 
the components necessary to encrypt the document). 
[0150] The securing client can prepare a specification 
of the desired security for the document to be secured. 
This can involve end-user interaction in a client, such as 
an email application like Outlook® software, provided 
by Microsoft Corporation of Redmond, Washington. The 
client can connect to the server via the RPC, authenti- 
cate, and send information up to the server (1 800). If the 
system is using server-side securing, the client can send 
the unencrypted document and the securing specifica- 
tion up to the server. If the system is using client-side 
securing, then only the specification need be sent. 
[0151] The server can authenticate the user, ensuring 
that he has permission to secure a document (1805). 
The service provider can provide a ticket (GUID) for the 
document (1810). The Access Control List specification 
can be given to the Access Control Manager so it can 
canonicalize the principals and possibly validate per- 
missions (1815). The ACM can first attempt to use an 
in-memory cache of canonical mappings. The storage 
provider can be queried for other cached canonical 
mappings (1 820). Principal providers can be queried for 
all non-cached noncanonical entries (1 825). The canon- 
icalized ACL can be persisted in the storage provider to 
allow for subsequent modification of the ACL (1 830). 
[0152] The information to be encrypted and stored in 
the document (e.g., ticket and ACL) can be provided to 
the Crypo Service Provider (1835), which can create a 
document key that will be used to encrypt the document. 



If document shredding is not desired, then document 
key, ticket, and ACL can be encrypted using the server 
public key. If shredding is desired, then the document 
key should not be encrypted as the key should not leave 

s the server. If the system is using server-side securing, 
the encrypted ticket data from the Cryptography module 
can be embedded within the document, and the docu- 
ment key can be used to encrypt the document (1 840). 
If the system is using client-side securing, this is not 

to needed. 

[0153] The system can audit that a document was se- 
cured (1845). If the system is using server-side secur- 
ing, the encrypted file can be returned to the client 
(1 850). Otherwise the encrypted ticket data and the doc- 

15 ument key can be returned to the client (1850). If the 
system is using client-side securing, the document se- 
curer on the client can embed the encrypted ticket data 
and encrypt the document using the document key on 
the client (1855). 

20 [0154] FIG. 19 is a block diagram illustrating server- 
side ACL evaluation workflow in the document control 
server of FIG. 9. When the server performs an operation 
that involves permissions, the server can first determine 
the authenticated user identity (1900). The encrypted 

25 server control information within the document can be 
decrypted (1910). The ticket in the encrypted control in- 
formation can be used to retrieve the most recent doc- 
ument ACL from the storage service provider (1920). 
The Access Control Manager can evaluate the ACL, de- 

30 termining which permissions are relevant to the authen- 
ticated user (1930). The ACL may reference groups, 
and so the storage provider can be queried to determine 
which groups the authenticated user belongs to (1 940). 
[0155] FIG. 20 is a block diagram illustrating online 

35 document viewing workflow in the document control 
server of FIG. 9. Viewing a document while online can 
involve two major phases. The first phase involves de- 
termining which permissions the authenticated user 
has, and the second phase involves returning the doc- 

40 ument key to decrypt the document on the client. When 
a document is to be viewed online, a viewing application 
can open a secured document and recognize that the 
document is associated with the control server (e.g., the 
document can involve a security handler in the viewing 

■*5 client). Using the server RPC, the viewing application 
can transmit to the server the encrypted control infor- 
mation within the encrypt dictionary in the document 
(2000). The server can evaluate the ACL as an opera- 
tion that involves permissions (2010), as described 

50 above in connection with FIG. 1 9. Then, the storage pro- 
vider can be queried to ensure this document has not 
been revoked (2020). The document key can be extract- 
ed from the control information (2030). The server can 
audit the online viewing of this document (2040). The 

55 most recent ACL, the rules for viewing this document, 
as well as the document key can then be returned to the 
viewing client (2050). The viewing application can then 
enforce the permissions (e.g., the security handler can 
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inform the viewing application what permissions to en- 
force, and provide the decryption key such that the doc- 
ument can be viewed). 

[0156] FIG. 21 is a block diagram illustrating revoca- 
tion workflow in the document control server of FIG. 9. 
The client can send the encrypted control information to 
the server (2100). The server can determine whether 
the authenticated user has permission to revoke the 
document (2110), as described above in connection 
with FIG. 1 9. The server can then revoke the document 
(2120). The client can receive an acknowledgement 
(2130). 

[0157] FIG. 22 is a block diagram illustrating audit 
events retrieval workflow in the document control server 
of FIG. 9. The client can send the encrypted control in- 
formation to the server (2200). The server can deter- 
mine whether the authenticated user has permission to 
get the audit history for this document (2210), as de- 
scribed above in connection with FIG. 19. The storage 
provider can be queried to determine what events are 
relevant to this document (2220). The client can then 
receive and display the audit information to the user 
(2230). 

[0158] FIG. 23 is a block diagram illustrating a docu- 
ment control system with multiple document control 
servers 2360. The system can use a three tier architec- 
ture to provide reliability and scalability. Clients 2310, 
2320, 2330 in an application tier 2300 communicate with 
the document control servers 2360 in a business logic 
tier 2350, which communicate with enterprise systems 
(e.g., a database management system (DBMS) 2380) 
in a storage tier 2370. All server state that is not specific 
to that particular instance of the server can be stored in 
the third tier 2370 so that multiple server instances can 
share such state. 

[0159] When multiple document control server in- 
stances 2360 are used, requests can be routed to other 
servers if one goes down. A load balancer 2340 can 
handle routing of requests to the server instances 2360. 
Within a server itself, high reliability can be achieved by 
writing the server in a language using managed code, 
such as Java or a .NET language. In order to manage 
many canonical and non-canonical principals, two lev- 
els of cache can be provided for principal information. 
A server 2360 can have an in-memory cache of canon- 
ical mapping and group membership for recently que- 
ried canonical users. Many document control servers 
can share the secondary cache within the storage pro- 
vider. 

[0160] Should the desired information not exist within 
either of these caches, the servers can directly access 
the direct principal providers within the Access Control 
service provider and then cache the information both lo- 
cally and within the storage provider. Group member- 
ship information should be batch processed such that it 
can be retrieved as needed in a reasonable amount of 
time. One of the document control servers, as asecond- 
ary service, can be designated a master and have the 



responsibility of performing the batch processing tasks. 
In many cases, the actual securing can be done on the 
client to remove the overhead of transferring the docu- 
ment to and from the server and to reduce the load on 
5 the server. Likewise, with client-side securing, the client 
can also perform the document encryption, further de- 
creasing server load. 

[0161] The three-tier architecture allows server repli- 
cas to be added to scale to large enterprises. Docu- 

10 ments can be tethered to a cluster of servers instead of 
to a specific hostname, as described above. DNS (Do- 
main Naming System) round-robin can be added to the 
system to allow for additional hardware to act as docu- 
ment control servers. The servers can contain no state, 

15 so the hardware scalability concern can be reduced to 
the standard "one database" problem. Algorithms re- 
garding principal management can be designed to be O 
(1 ) for individual operations and O(n) for aggregate op- 
erations (batch processing, etc.). 

20 [0162] The invention and all of the functional opera- 
tions described in this specification can be implemented 
in digital electronic circuitry, or in computer hardware, 
firmware, software, or in combinations of them. Appara- 
tus of the invention can be implemented in a software 

25 product (e.g., acomputer program product) tangibly em- 
bodied in a machine-readable storage device for exe- 
cution by a programmable processor; and processing 
operations of the invention can be performed by a pro- 
grammable processor executing a program of instruc- 

30 tions to perform functions of the invention by operating 
on input data and generating output. The invention can 
be implemented advantageously in one or more soft- 
ware programs that are executable on a programmable 
system including at least one programmable processor 

35 coupled to receive data and instructions from, and to 
transmit data and instructions to, adata storage system, 
at least one input device, and at least one output device. 
Each software program can be implemented in a high- 
level procedural or object-oriented programming lan- 

40 guage, or in assembly or machine language if desired; 
and in any case, the language can be a compiled or in- 
terpreted language. Suitable processors include, by 
way of example, both general and special purpose mi- 
croprocessors. Generally, a processor will receive in- 

■*5 structions and data from a read-only memory, a random 
access memory and/or a machine-readable signal (e.g., 
a digital signal received through a network connection). 
Generally, a computer will include one or more mass 
storage devices for storing data files; such devices in- 

50 elude magnetic disks, such as internal hard disks and 
removable disks, magneto-optical disks, and optical 
disks. Storage devices suitable for tangibly embodying 
software program instructions and data include all forms 
of non-volatile memory, including by way of example 

55 semiconductor memory devices, such as EPROM (elec- 
trically programmable read-only memory), EEPROM 
(electrically erasable programmable read-only memo- 
ry), and flash memory devices; magnetic disks such as 



20 



39 



EP 1 528 455 A1 



40 



internal hard disks and removable disks; magneto-opti- 
cal disks; and CD-ROM disks. Any of the foregoing can 
be supplemented by, or incorporated in, ASICs (appli- 
cation-specific integrated circuits). 

[0163] The invention has been described in terms of s 
particular embodiments. Other embodiments are within 
the scope of the following claims. For example, the op- 
erations of the invention can be performed in a different 
order and still achieve desirable results. The operations 
can be provided as a hosted service, using a subscrip- 10 
tion business model, and integrations can be performed 
with generally available system infrastructure available 
over the Internet. The document version control tech- 
niques can be implemented using peer-to-peer systems 
and techniques. Moreover, the sets of permissions for 15 
documents can be extended to cover various actions 
with respect to document content given different work- 
flows (e.g., permissions that allow only certain people 
to sign a document, or portions of a document, and/or 
permissions that control who may fill out and/or view dif- 20 
ferent sections of an electronic form). 
[0164] Additionally, an alternative to always synchro- 
nizing policy updates but not necessarily other ACLs, 
can involve providing information regarding which ACLs 
in the system have changed. Synchronization opera- 25 
tions can then be divided into high and low priority op- 
erations. High priority synchronizations can occur in the 
background more frequently, and provide indications of 
when information has changed. For example, an indica- 
tion of which access control lists and policies have 30 
changed since the client's last synchronization. Low pri- 
ority synchronization operations can entail how informa- 
tion has changed. For example, this can include the of- 
fline access information for every document in the sys- 
tem that has changed. Synchronizing how access con- 35 
trol information has changed should be generally more 
resource intensive than a summary of what has 
changed. If access control for a document has been 
modified and the client is aware of a modification but 
has not performed a low priority synchronization, the 40 
system can be conservative and an implementation can 
prevent access to that document until the low priority 
synchronization has taken place. 



2. The method of claim 1 , wherein pre-authorizing the 
client comprises comparing a time of last recorded 
client-synchronization with a time of last change in 
user-group information for the user. 

3. The method of one of the preceding claims, wherein 
pre-authorizing the client comprises comparing cur- 
rent user-group information for the user with re- 
ceived user-group information for the user from the 
client. 

4. The method of one of the preceding claims, wherein 
the client allows actions with respect to the electron- 
ic document based on document-permissions infor- 
mation residing in the electronic document. 

5. The method of one of the preceding claims, wherein 
the offline access information further comprises 
document-permissions information associated with 
multiple documents, including the electronic docu- 
ment, and the client allows actions with respect to 
the electronic document based on the document- 
permissions information. 

6. The method of one of the preceding claims, wherein 
receiving a request comprises receiving a request 
from the client to take an action with respect to a 
second document. 

7. The method of claim 6, further comprising verifying 
the user at the client as an authenticated user. 

8. The method of claim 6 or 7, wherein the offline ac- 
cess information further comprises: 

at least one user-specific key; 

at least one group-specific key, including the 

first key; and 

at least one set of document-permissions infor- 
mation associated with multiple documents. 

9. The method of claim 8, furthercomprising receiving 
an offline audit log from the client. 



45 10. The method of claim 8 or 9, wherein the at least one 

Claims set of document-permissions information compris- 
es one or more policies associated with the second 

1. A method comprising: document, and the offline access information fur- 
ther comprises a document revocation list. 

receiving a request from a client; and so 

pre-authorizing the client, in response to the re- 11. The method of claim 8, 9 or 1 0, wherein the offline 

quest, to allow actions by a user as a member access information further comprises at least one 

of a group of users by sending to the client of- set of document-permissions information associat- 

fline access information comprising a first key ed with a specific document selected based on syn- 

associated with the group, the first key being 55 chronization prioritization information, 
useable at the client to access an electronic 

document by decrypting a second key in the 12. A method comprising: 
electronic document. 
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receiving from a document control server, when 
online, offline access information comprising a 
first key associated with a group of users of the 
document control server; and 
allowing access to an electronic document, s 
when offline, by performing operations com- 
prising using the first key to decrypt a second 
key in the electronic document and governing 
actions with respect to the electronic document 
based on document-permissions information 10 
associated with the electronic document. 



13. The method of claim 12, wherein governing actions 
with respect to the electronic document comprises 
obtaining the document-permissions information 15 
from the electronic document. 

14. The method of claim 12 or 13, wherein governing 
actions with respect to the electronic document 
comprises: 20 



15. The method of one of the preceding claims 12 to 

14, wherein the offline access information compris- 
es at least one user-specific key, at least one group- 30 
specific key, including the first key, at least one set 

of document-permissions information associated 
with multiple documents, and a document revoca- 
tion list. 

35 

16. The method of one of the preceding claims 12 to 

15, further comprising preventing access to the doc- 
ument, when offline, if a difference between a cur- 
rent time and a receipt time of the offline access in- 
formation exceeds a server-synchronization-fre- 40 
quency parameter. 

17. The method of claim 16, wherein the server-syn- 
chronization-frequency parameter is specific to the 
document. 45 

18. The method of one of the preceding claims 12 to 
17, further comprising: 



cryption key useable in decrypting the encrypt- 
ed electronic document, the encryption key be- 
ing encrypted with a key generated by, and as- 
sociated with a group of users of, the document 
control server. 

20. The method of claim 1 9, wherein the encryption key 
comprises a session key generated by the docu- 
ment control server, encrypting the electronic doc- 
ument comprises encrypting the electronic docu- 
ment using a document key, and incorporating com- 
prises incorporating into the encrypted electronic 
document a document security payload comprising 
the document key and the document-permissions 
information, the document security payload being 
encrypted using the session key. 

21 . The method of claim 20, wherein the document se- 
curity payload further comprises a document iden- 
tifier assigned by the document control server, and 
incorporating further comprises incorporating into 
the encrypted electronic document a copy of the 
session key encrypted using a public key associat- 
ed with the document control server. 

22. The method of one of the preceding claims 19 to 
21 , wherein the document-permissions information 
specifies access permissions at a level of granular- 
ity smaller than the electronic document. 

23. A software product tangibly embodied in a machine- 
readable medium, the software product comprising 
instructions operable to cause one or more data 
processing apparatus to perform operations com- 
prising: 

receiving a request from a client; and 
pre-authorizing the client, in response to the re- 
quest, to allow actions by a user as a member 
of a group of users by sending to the client of- 
fline access information comprising a first key 
associated with the group, the first key being 
useable at the client to access an electronic 
document by decrypting a second key in the 
electronic document. 

24. The software product of claim 23, wherein pre-au- 
thorizing the client comprises comparing a time of 
last recorded client-synchronization with a time of 
last change in user-group information for the user. 

25. The software product of claim 23 or 24, wherein pre- 
authorizing the client comprises comparing current 
user-group information for the user with received 
user-group information for the user from the client. 

26. The software product of one of the preceding claim 
23 to 25, wherein the client allows actions with re- 



maintaining an offline audit log; and so 
uploading the offline audit log when online. 

19. A method comprising: 

encrypting an electronic document; and 55 
incorporating into the encrypted electronic doc- 
ument an address of a document control server, 
document-permissions information, and an en- 



identifying a document policy reference in the 
electronic document; and 
obtaining locally retained document-permis- 
sions information based on the document poli- 25 
cy reference. 
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spect to the electronic document based on docu- 
ment-permissions information residing in the elec- 
tronic document. 

27. The software product of one of the preceding claims 
23 to 26, wherein the offline access information fur- 
ther comprises document-permissions information 
associated with multiple documents, including the 
electronic document, and the client allows actions 
with respect to the electronic document based on 
the document-permissions information. 

28. The software product of one of the preceding claims 
23 to 27, wherein receiving a request comprises re- 
ceiving a request from the client to take an action 
with respect to a second document. 

29. The software product of claim 28, wherein the op- 
erations further comprise verifying the user at the 
client as an authenticated user. 

30. The software product of claim 28 or 29, wherein the 
offline access information further comprises: 

at least one user-specific key; 

at least one group-specific key, including the 

first key; and 

at least one set of document-permissions infor- 
mation associated with multiple documents. 

31. The software product of claim 30, wherein the op- 
erations further comprise receiving an offline audit 
log from the client. 

32. The software product of claim 30 or 31 , wherein the 
at least one set of document-permissions informa- 
tion comprises one or more policies associated with 
the second document, and the offline access infor- 
mation further comprises a document revocation 
list. 

33. The software product of claim 30, 31 or 32, wherein 
the offline access information further comprises at 
least one set of document-permissions information 
associated with a specific document, and the oper- 
ations further comprise selecting the document- 
specific document-permissions information based 
on synchronization prioritization information. 

34. A software product tangibly embodied in a machine- 
readable medium, the software product comprising 
instructions operable to cause one or more data 
processing apparatus to perform operations com- 
prising: 

receiving from a document control server, when 
online, offline access information comprising a 
first key associated with a group of users of the 



document control server; and 
allowing access to an electronic document, 
when offline, by performing operations com- 
prising using the first key to decrypt a second 
s key in the electronic document and governing 

actions with respect to the electronic document 
based on documerit-permissions information 
associated with the electronic document. 

to 35. The software product of claim 34, wherein govern- 
ing actions with respect to the electronic document 
comprises obtaining the document-permissions in- 
formation from the electronic document. 

15 36. The software product of claim 34 or 35, wherein 
governing actions with respect to the electronic doc- 
ument comprises: 

identifying a document policy reference in the 
20 electronic document; and 

obtaining locally retained document-permis- 
sions information based on the document poli- 
cy reference. 

25 37. The software product of claim 34, 35 or 36, wherein 
the offline access information comprises at least 
one user-specific key, at least one group-specific 
key, including the first key, at least one set of doc- 
ument-permissions information associated with 

30 multiple documents, and a document revocation 
list. 

38. The software product of one of the preceding claims 
34 to 37, wherein the operations further comprise 
35 preventing access to the document, when offline, if 
a difference between a current time and a receipt 
time of the offline access information exceeds a 
server-synchronization-frequency parameter. 

40 39. The software product of claim 38, wherein the serv- 
er-synchronization-frequency parameter is specific 
to the document. 

40. The software product of one of the preceding claims 
■*5 34 to 39, wherein the operations further comprise: 

maintaining an offline audit log; and 
uploading the offline audit log when online. 

50 41. A software product tangibly embodied in a machine- 
readable medium, the software product comprising 
instructions operable to cause one or more data 
processing apparatus to perform operations com- 
prising: 

55 

encrypting an electronic document; and 
incorporating into the encrypted electronic doc- 
u ment an address of adocument control server, 
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document-permissions information, and an en- 
cryption key useable in decrypting the encrypt- 
ed electronic document, the encryption key be- 
ing encrypted with a key generated by, and as- 
sociated with a group of users of, the document 
control server. 

42. The software product of claim 41, wherein the en- 
cryption key comprises a session key generated by 
the document control server, encrypting the elec- 
tronic document comprises encrypting the electron- 
ic document using a document key, and incorporat- 
ing comprises incorporating into the encrypted elec- 
tronic document a document security payload com- 
prising the document key and the document-per- 
missions information, the document security pay- 
load being encrypted using the session key. 

43. The software product of claim 42, wherein the doc- 
ument security payload further comprises a docu- 
ment identifier assigned by the document control 
server, and incorporating further comprises incor- 
porating into the encrypted electronic document a 
copy of the session key encrypted using a public 
key associated with the document control server. 

44. The software product of claim 41 , 42 or 43, wherein 
the document-permissions information specifies 
access permissions at a level of granularity smaller 
than the electronic document. 

45. A system comprising: 

a document control server that synchronizes of- 
fline access information with a client in re- 
sponse to a client request, the offline access 
information comprising a first key associated 
with a group, the first key being useable at the 
client to access an electronic document by de- 
crypting a second key in the electronic docu- 
ment; and 

the client that allows access to the electronic 
document, when offline, by a user as a member 
of the group, using the first key to decrypt the 
second key in the electronic document and gov- 
erning actions with respect to the electronic 
document based on document-permissions in- 
formation associated with the electronic docu- 
ment. 

46. The system of claim 45, wherein the electronic doc- 
ument comprises the document-permissions infor- 
mation. 

47. The system of claim 46, wherein the second key 
comprises a session key generated by the docu- 
ment control server, and the electronic document 
further comprises a document security payload 



comprising a document key and the document-per- 
missions information, the document security pay- 
load being encrypted using the session key. 

5 48. The system of one of the preceding claims 45 to 47, 
wherein the offline access information further com- 
prises: 

at least one user-specific key; 
to at least one group-specific key, including the 

first key; and 

at least one set of document-permissions infor- 
mation associated with multiple documents. 

15 49. The system of one of the preceding claims 45 to 48, 
wherein the client comprises an agent that periodi- 
cally contacts the document control server to syn- 
chronize the offline access information. 

20 50. The system of one of the preceding claims 45 to 49, 
wherein the document control server comprises: 

a server core with configuration and logging 
components; 

25 an internal services component that provides 

functionality across dynamically loaded meth- 
ods; and 

dynamically loaded external service providers, 
including one or more access control service 
30 providers. 

51 . The system of one of the preceding claims 45 to 50, 
further comprising: 

35 a business logic tier comprising a cluster of doc- 

ument control servers, including the document 
control server; 

an application tier including the client compris- 
ing a viewer client, a securing client, and an ad- 
40 ministration client; and 

a load balancer that routes client requests to 
the document control servers. 

52. The system of one of the preceding claims 45 to 51 , 
■*5 wherein the client request comprises a request from 

the client to take an action with respect to a second 
document. 

53. The system of claim 52, wherein the document con- 
so trol server comprises a permissions-broker server 

including a translation component, the second doc- 
ument comprises a document secured previously 
by the permissions-broker server, and the transla- 
tion component being operable to translate first 
55 document-permissions information in a first permis- 
sions-definition format into second document-per- 
missions information in a second permissions-def- 
inition format in response to the request being re- 
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ceived from the client. 

54. The system of claim 52 or 53, wherein the server 
comprises a permissions-broker server operable to 
identify information associated with the second doc- s 
ument in response to the request, the associated 
information being retained at the server and indicat- 
ing a third electronic document different from and 
associated with the second document, the server 
being operable to relate information concerning the 10 
third electronic document to the client to facilitate 

the action to be taken. 

55. The system of one of the preceding claims 52 to 54, 
wherein the server comprises a permissions-broker is 
server operable to obtain and send, in response to 

the request, a software program comprising instruc- 
tions operable to cause one or more data process- 
ing apparatus to perform operations effecting an au- 
thentication procedure, and the client uses the au- 20 
thentication program to identify a current user and 
control the action with respect to the second docu- 
ment based on the current user and document-per- 
missions information associated with the second 
document. 25 

56. A system comprising: 

server means for transparently providing offline 
access information for controlled documents to 30 
pre-authorize a client to allow actions by a user 
as a member of a group of users, the offline ac- 
cess information comprising a first key associ- 
ated with the group, the first key being useable 
at the client to access an electronic document 35 
by decrypting a second key in the electronic 
document; and 

client means for accessing the electronic doc- 
ument using the offline access information. 

40 

57. The system of claim 56, further comprising: 

server means for dynamically obtaining and 
sending authentication processes in response 
to client requests to take actions with respect 45 
to electronic documents; and 
client means for interfacing with a received au- 
thentication process to identify a current user 
and for controlling actions with respect to elec- 
tronic documents based on the current user so 
and document-permissions information. 
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